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 20201203085359.GC8050@nol
Whole thread Raw
In response to Re: pg_stat_statements oddity with track = all  (Sergei Kornilov <sk@zsrv.org>)
Responses Re: pg_stat_statements oddity with track = all
List pgsql-hackers
On Thu, Dec 03, 2020 at 11:40:22AM +0300, Sergei Kornilov wrote:
> Hello
> 
> > To get an increase in the number of records that means that the same
> > statement
> > would appear at top level AND nested level. This seems a corner case with
> > very low
> > (neglectible) occurence rate.
> 
> +1
> I think splitting fields into plans_toplevel / plans_nested will be less convenient. And more code with higher chance
ofcopypaste errors
 

As I mentioned in a previous message, I really have no idea if that would be a
corner case or not.  For instance with native partitioning, the odds to have
many different query executed both at top level and as a nested statement may
be quite higher.



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: pg_stat_statements oddity with track = all
Next
From: Bharath Rupireddy
Date:
Subject: Re: Multi Inserts in CREATE TABLE AS - revived patch