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
