Re: Issue in recent pg_stat_statements?

Поиск
Список
Период
Сортировка
От David Christensen
Тема Re: Issue in recent pg_stat_statements?
Дата
Msg-id CAOxo6XK5f0VPM-RhgpZq2s6wiOV6isnEC2tsgNyPfZd8pD0PYg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Issue in recent pg_stat_statements?  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: Issue in recent pg_stat_statements?
Список pgsql-hackers


On Mon, Apr 26, 2021 at 12:18 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
On Mon, Apr 26, 2021 at 11:40 PM David Christensen
<david.christensen@crunchydata.com> wrote:
>>
>> > Is this an expected change, or is this in fact broken?  In previous revisions, this was showing the INSERT and SELECT at the very least.  I'm unclear as to why the regression test is still passing, so want to verify that I'm not doing something wrong in the testing.
>>
>> Yes, you want to look into the queryid functionality. See
>> https://www.postgresql.org/message-id/flat/35457b09-36f8-add3-1d07-6034fa585ca8%40oss.nttdata.com
>>
>> Interface changes may still be coming in 14 for that. Or warnings.
>
>
> Hmm, I'm unclear as to why you would potentially want to use pg_stat_statements *without* this functionality.

Using pg_stat_statements with a different query_id semantics without
having to fork pg_stat_statements.

I can see that argument for allowing alternatives, but the current default of nothing seems to be particularly non-useful, so some sensible default value would seem to be in order, or I can predict a whole mess of future user complaints.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Mark Dilger
Дата:
Сообщение: Re: pg_amcheck contrib application
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Issue in recent pg_stat_statements?