Re: pg_stat_statements oddity with track = all
Julien Rouhaud <rjuju123@gmail.com>
From: Julien Rouhaud <rjuju123@gmail.com>
To: Sergei Kornilov <sk@zsrv.org>
Cc: legrand legrand <legrand_legrand@hotmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2020-12-04T08:15:48Z
Lists: pgsql-hackers
Attachments
On Thu, Dec 03, 2020 at 04:53:59PM +0800, Julien Rouhaud wrote: > 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 of copypaste 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. The consensus seems to be adding a new boolean toplevel flag in the entry key, so PFA a patch implementing that. Note that the key now has padding, so memset() calls are required.
Commits
-
Merge v1.10 of pg_stat_statements into v1.9
- 5844c23dc505 14.0 landed
-
Track identical top vs nested queries independently in pg_stat_statements
- 6b4d23feef6e 14.0 landed