| From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
|---|---|
| To: | Magnus Hagander <magnus(at)hagander(dot)net> |
| Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Nitin Jadhav <nitinjadhavpostgres(at)gmail(dot)com>, Hannu Krosing <hannuk(at)google(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, Atsushi Torikoshi <atorik(at)gmail(dot)com>, Tatsuro Yamada <tatsuro(dot)yamada(dot)tf(at)nttcom(dot)co(dot)jp>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Evgeny Efimkin <efimkin(at)yandex-team(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? |
| Date: | 2021-04-23 10:40:33 |
| Message-ID: | 48073e43-0d55-0f74-e456-4f533c8405a6@oss.nttdata.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2021/04/23 19:11, Magnus Hagander wrote:
> On Fri, Apr 23, 2021 at 12:04 PM Fujii Masao
> <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
>>
>>
>>
>> On 2021/04/23 18:46, Magnus Hagander wrote:
>>> On Fri, Apr 23, 2021 at 9:10 AM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matthias van de Meent | 2021-04-23 10:45:45 | Re: Iterating on IndexTuple attributes and nbtree page-level dynamic prefix truncation |
| Previous Message | Bharath Rupireddy | 2021-04-23 10:21:10 | How to test Postgres for any unaligned memory accesses? |