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

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Дата
Msg-id 48073e43-0d55-0f74-e456-4f533c8405a6@oss.nttdata.com
обсуждение исходный текст
Ответ на Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?  (Magnus Hagander <magnus@hagander.net>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: How to test Postgres for any unaligned memory accesses?
Следующее
От: Matthias van de Meent
Дата:
Сообщение: Re: Iterating on IndexTuple attributes and nbtree page-level dynamic prefix truncation