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  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Closing commitfest 2013-11