From: | Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_stat_statements oddity with track = all |
Date: | 2020-12-02 06:08:06 |
Message-ID: | CANNMO+KrVxMTrzSJLkrkENQX7utVYo1SEyaW54N+Y-Zjew=wbQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Dec 1, 2020 at 8:05 PM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> Hi,
>
> Someone raised an interested point recently on pg_stat_kcache extension for
> handling nested statements, which also applies to pg_stat_statements.
>
...
> The only idea I have for that is to add a new field to entry key, for
> instance
> is_toplevel.
This particular problem often bothered me when dealing with
pg_stat_statements contents operating under "track = all" (especially when
performing the aggregated analysis, like you showed).
I think the idea of having a flag to distinguish the top-level entries is
great.
> The immediate cons is obviously that it could amplify quite a lot
> the number of entries tracked, so people may need to increase
> pg_stat_statements.max to avoid slowdown if that makes them reach frequent
> entry eviction.
>
If all top-level records in pg_stat_statements have "true" in the new
column (is_toplevel), how would this lead to the need to increase
pg_stat_statements.max? The number of records would remain the same, as
before extending pg_stat_statements.
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2020-12-02 06:32:41 | Re: pg_stat_statements oddity with track = all |
Previous Message | Pavel Stehule | 2020-12-02 05:48:02 | Re: proposal: unescape_text function |