Re: compute_query_id and pg_stat_statements

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: compute_query_id and pg_stat_statements
Дата
Msg-id BF76270E-87A4-4406-80F9-70AED74C4D4C@dunslane.net
обсуждение исходный текст
Ответ на Re: compute_query_id and pg_stat_statements  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: compute_query_id and pg_stat_statements  (Julien Rouhaud <rjuju123@gmail.com>)
Re: compute_query_id and pg_stat_statements  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers

Sent from my iPhone

> On May 14, 2021, at 8:35 AM, Bruce Momjian <bruce@momjian.us> wrote:
>
> On Thu, May 13, 2021 at 09:41:42PM -0400, Bruce Momjian wrote:
>>> On Fri, May 14, 2021 at 09:40:15AM +0800, Julien Rouhaud wrote:
>>> On Fri, May 14, 2021 at 8:13 AM Bruce Momjian <bruce@momjian.us> wrote:
>>>>
>>>> On Thu, May 13, 2021 at 08:04:37PM -0400, Álvaro Herrera wrote:
>>>>> Here's a first attempt at what was suggested.  If you say "auto" it
>>>>> remains auto in SHOW, but it gets enabled if a module asks for it.
>>>>>
>>>>> Not final yet, but I thought I'd throw it out for early commentary ...
>>>>
>>>> I certainly like this idea better than having the extension change the
>>>> output of the GUC.
>>>
>>> Oh, I didn't understand that it was the major blocker.  I'm fine with it too.
>>
>> I think if we keep the output as 'auto', and document that you check
>> pg_stat_activity for a hash to see if it is enabled, that gets us pretty
>> far.
>
> I think keeping the output as 'auto', and documenting that this query
> must be run to determine if the query id is being computed:
>
>    SELECT query_id
>    FROM pg_stat_activity
>    WHERE pid = pg_backend_pid();
>
> is the right approach.

I’d rather we added a specific function. This is not really obvious.

Cheers

Andrew




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

Предыдущее
От: Chapman Flack
Дата:
Сообщение: Re: allow specifying direct role membership in pg_hba.conf
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: compute_query_id and pg_stat_statements