Date: Wed, 2 Dec 2020 16:24:02 +0800
From: Julien Rouhaud <rjuju123@gmail.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Nikolay Samokhvalov <samokhvalov@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_stat_statements oddity with track = all
Message-ID: <20201202082402.GB51769@nol>
References: <20201202040516.GA43757@nol>
 <CANNMO+KrVxMTrzSJLkrkENQX7utVYo1SEyaW54N+Y-Zjew=wbQ@mail.gmail.com>
 <20201202063241.GA51769@nol>
 <dc48d183-65a2-8f12-3581-ab8f3faeab8b@oss.nttdata.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <dc48d183-65a2-8f12-3581-ab8f3faeab8b@oss.nttdata.com>
Precedence: bulk

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@gmail.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.