Re: compute_query_id and pg_stat_statements - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: compute_query_id and pg_stat_statements
Date
Msg-id 20210514161601.7wguwkdvgw4cugw3@nol
Whole thread Raw
In response to Re: compute_query_id and pg_stat_statements  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On Fri, May 14, 2021 at 12:04:05PM -0400, Andrew Dunstan wrote:
> 
> > 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.

We could, but I don't know how much this will be used in practice.  The only
way someone would try to know if "auto" means that query_id are computed is if
she has an extension like pg_stat_statements, and she will probably just check
that anyway, and will get a warning if query_id are *not* computed.

That being said no objection to an SQL wrapper around a query like it.



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: compute_query_id and pg_stat_statements
Next
From: Bruce Momjian
Date:
Subject: Re: compute_query_id and pg_stat_statements