Re: pg_stat_statements oddity with track = all

On Wed, Dec 02, 2020 at 03:52:37PM +0900, Fujii Masao wrote:
>
> On 2020/12/02 15:32, Julien Rouhaud wrote:
> > On Tue, Dec 01, 2020 at 10:08:06PM -0800, Nikolay Samokhvalov wrote:
> > > On Tue, Dec 1, 2020 at 8:05 PM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> > >
> > > > 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.
>
> [...]
>
> Just idea; instead of boolean is_toplevel flag, what about
> counting the number of times when the statement is executed
> in toplevel, and also in nested level?

Ah, indeed that would avoid extraneous entries. FTR we would also need that
for the planning part.

The cons I can see is that it'll make the counters harder to process (unless we
provide a specific view for the top-level statements only for instance), and
that it assumes that doing a simple division is representative enough for the
top level/nested repartition. This might be quite off for in some cases, e.g.
big stored procedures due to lack of autovacuum, but that can't be worse than
what we currently have.