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
Re: compute_query_id and pg_stat_statements |
Список | 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 по дате отправления: