Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Date
Msg-id CABUevEwDLUrMGBvGdqFMyzZ1_NjQoRJTmncFCc7niRnSeB_Ckg@mail.gmail.com
Whole thread Raw
In response to Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?  (Fujii Masao <masao.fujii@oss.nttdata.com>)
List pgsql-hackers
On Fri, Apr 23, 2021 at 12:40 PM Fujii Masao
<masao.fujii@oss.nttdata.com> wrote:
>
>
>
> On 2021/04/23 19:11, Magnus Hagander wrote:
> > On Fri, Apr 23, 2021 at 12:04 PM Fujii Masao
> > <masao.fujii@oss.nttdata.com> wrote:
> >>
> >>
> >>
> >> On 2021/04/23 18:46, Magnus Hagander wrote:
> >>> On Fri, Apr 23, 2021 at 9:10 AM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 2021/04/22 18:23, Julien Rouhaud wrote:
> >>>>> On Thu, Apr 22, 2021 at 12:28:11AM +0900, Fujii Masao wrote:
> >>>>>>
> >>>>>> I found another small issue in pg_stat_statements docs. The following
> >>>>>> description in the docs should be updated so that toplevel is included?
> >>>>>>
> >>>>>>> This view contains one row for each distinct database ID, user ID and query ID
> >>>>>
> >>>>> Indeed!  I'm adding Magnus in Cc.
> >>>>>
> >>>>> PFA a patch to fix at, and also mention that toplevel will only
> >>>>> contain True values if pg_stat_statements.track is set to top.
> >>>>
> >>>> Thanks for the patch! LGTM.
> >>>
> >>> Agreed, in general. But going by the example a few lines down, I
> >>> changed the second part to:
> >>>           True if the query was executed as a top level statement
> >>> +       (if <varname>pg_stat_statements.track</varname> is set to
> >>> +       <literal>all</literal>, otherwise always false)
> >>
> >> Isn't this confusing? Users may mistakenly read this as that the toplevel
> >> column always indicates false if pg_stat_statements.track is not "all".
> >
> > Hmm. I think you're right. It should say "always true", shouldn't it?
>
> You're thinking something like the following?
>
>      True if the query was executed as a top level statement
>      (if <varname>pg_stat_statements.track</varname> is set to
>      <literal>top</literal>, always true)
>
> > So not just confusing, but completely wrong? :)
>
> Yeah :)

Ugh. I completely lost track of this email.

I've applied the change suggested above with another slight reordering
of the words:

+       (always true if <varname>pg_stat_statements.track</varname> is set to
+       <literal>top</literal>)


> I'm fine with the original wording by Julien.
> Of course, the parameter name should be corrected as you did, though.
>
> Or what about the following?
>
>      True if the query was executed as a top level statement
>      (this can be <literal>false</literal> only if
>      <varname>pg_stat_statements.track</varname> is set to
>      <literal>all</literal> and nested statements are also tracked)

I found my suggestion, once the final reordering of words was done,
easier to parse.

-- 
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: "ERROR: deadlock detected" when replicating TRUNCATE
Next
From: Pavel Stehule
Date:
Subject: Re: Schema variables - new implementation for Postgres 15