Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core
От | Peter Geoghegan |
---|---|
Тема | Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core |
Дата | |
Msg-id | CAM3SWZSX0GroNCKvgnxVaLxMqaWt8NTeDfZDZD_y_zU5XzeVjw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core
Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core |
Список | pgsql-hackers |
On Mon, Jan 20, 2014 at 12:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I see this is marked as ready for committer. Where does it stand in > relation to the other long-running thread about "calls under-estimation > propagation"? I was surprised to find that there isn't any CommitFest > entry linked to that thread, so I'm wondering if that proposal is > abandoned or what. If it's not, is committing this going to blow up > that patch? I believe that proposal was withdrawn. I think the conclusion there was that we should just expose queryid and be done with it. In a way, exposing the queryid enabled this work, because it provides an identifier that can be used instead of sending large query texts each call. > BTW, I'm also thinking that the "detected_version" kluge is about ready > to collapse of its own weight, or at least is clearly going to break in > future. What we need to do is embed the API version in the C name of the > pg_stat_statements function instead. I agree that it isn't scalable. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: