From: Masahiro Ikeda <ikedamsh@oss.nttdata.com>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Sergei Kornilov <sk@zsrv.org>
Cc: legrand legrand <legrand_legrand@hotmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: pg_stat_statements oddity with track = all
Date: Wed, 20 Jan 2021 19:39:18 +0900
Message-ID: <1ee636ea9e0a579b6bd6fdffa205aaa6@oss.nttdata.com> (raw)
In-Reply-To: <CAOBaU_b=YYgst4ErfFPTh-Ha7zb+Bd0H-_A8g-cpM2zh33wK5w@mail.gmail.com>
References: <CANNMO+KrVxMTrzSJLkrkENQX7utVYo1SEyaW54N+Y-Zjew=wbQ@mail.gmail.com>
<20201202063241.GA51769@nol>
<CANNMO++VRu2r17jqxBDFZF4++p+f4WE+VbvOPAQi_4BTwP4g=Q@mail.gmail.com>
<20201203010051.GA8050@nol>
<1606983372910-0.post@n3.nabble.com>
<1110111606984390@mail.yandex.ru>
<20201203085359.GC8050@nol>
<20201204081548.GA76762@nol>
<109201607072216@mail.yandex.ru>
<20201204100913.GB76762@nol>
<20201227083857.GA97249@nol>
<4dce029c72fc5eb084c5353f31daa13f@oss.nttdata.com>
<CAOBaU_b=YYgst4ErfFPTh-Ha7zb+Bd0H-_A8g-cpM2zh33wK5w@mail.gmail.com>
On 2021-01-20 18:14, Julien Rouhaud wrote:
> On Tue, Jan 19, 2021 at 4:55 PM Masahiro Ikeda
> <ikedamsh@oss.nttdata.com> wrote:
>> I tested the "update" command can work.
>> postgres=# ALTER EXTENSION pg_stat_statements UPDATE TO '1.10';
>>
>> Although the "toplevel" column of all queries which already stored is
>> 'false',
>> we have to decide the default. I think 'false' is ok.
>
> Mmm, I'm not sure that I understand this result. The "toplevel" value
> is tracked by the C code loaded at startup, so it should have a
> correct value even if you used to have the extension in a previous
> version, it's just that you can't access the toplevel field before
> doing the ALTER EXTENSION pg_stat_statements UPDATE. There's also a
> change in the magic number, so you can't use the stored stat file from
> a version before this patch.
>
> I also fail to reproduce this behavior. I did the following:
>
> - start postgres with pg_stat_statements v1.10 (so with this patch) in
> shared_preload_libraries
> - CREATE EXTENSION pg_stat_statements VERSION '1.9';
> - execute a few queries
> - ALTER EXTENSION pg_stat_statements UPDATE;
> - SELECT * FROM pg_stat_statements reports the query with toplvel to
> TRUE
>
> Can you share a way to reproduce your findings?
Sorry for making you confused. I can't reproduce although I tried now.
I think my procedure was something wrong. So, please ignore this
comment, sorry about that.
>> B. check logic whether a query is top-level or not in pg_stat_kcache
>>
>> This patch uses the only exec_nested_level to check whether a query is
>> top-level or not.
>> The reason is nested_level is less useful and I agree.
>
> Do you mean plan_nest_level is less useful?
I think so. Anyway, it's important to correspond core's implementation
because pg_stat_statements and pg_stat_kcache are used at the same time.
Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: ikedamsh@oss.nttdata.com, rjuju123@gmail.com, sk@zsrv.org, legrand_legrand@hotmail.com
Subject: Re: pg_stat_statements oddity with track = all
In-Reply-To: <1ee636ea9e0a579b6bd6fdffa205aaa6@oss.nttdata.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox