MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 20 Jan 2021 19:39:18 +0900
From: Masahiro Ikeda <ikedamsh@oss.nttdata.com>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Sergei Kornilov <sk@zsrv.org>, legrand legrand
 <legrand_legrand@hotmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: pg_stat_statements oddity with track = all
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>
Message-ID: <1ee636ea9e0a579b6bd6fdffa205aaa6@oss.nttdata.com>
User-Agent: Roundcube Webmail/1.1.9
Precedence: bulk

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