Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

Fujii Masao <masao.fujii@oss.nttdata.com>

From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Magnus Hagander <magnus@hagander.net>
Cc: Julien Rouhaud <rjuju123@gmail.com>, Bruce Momjian <bruce@momjian.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Tom Lane <tgl@sss.pgh.pa.us>, Nitin Jadhav <nitinjadhavpostgres@gmail.com>, Hannu Krosing <hannuk@google.com>, Robert Haas <robertmhaas@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, Michael Paquier <michael@paquier.xyz>, torikoshia <torikoshia@oss.nttdata.com>, Atsushi Torikoshi <atorik@gmail.com>, Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Evgeny Efimkin <efimkin@yandex-team.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-04-23T10:40:33Z
Lists: pgsql-hackers

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 :)

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)

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



Commits

  1. Clarify description of pg_stat_statements columns

  2. Fix wording in description of pg_stat_statements.toplevel

  3. Mention that toplevel is part of pg_stat_statements key.

  4. adjust query id feature to use pg_stat_activity.query_id

  5. Update copyright for 2021

  6. Take the statistics collector out of the loop for monitoring backends'