Re: pg_stat_statements oddity with track = all - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: pg_stat_statements oddity with track = all
Date
Msg-id 20201202082402.GB51769@nol
Whole thread Raw
In response to Re: pg_stat_statements oddity with track = all  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: pg_stat_statements oddity with track = all
List pgsql-hackers
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.



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: proposal: unescape_text function
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions