Re: pg_stat_statements oddity with track = all
Nikolay Samokhvalov <samokhvalov@gmail.com>
From: Nikolay Samokhvalov <samokhvalov@gmail.com>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-12-02T06:08:06Z
Lists: pgsql-hackers
On Tue, Dec 1, 2020 at 8:05 PM Julien Rouhaud <rjuju123@gmail.com> wrote: > Hi, > > 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. This particular problem often bothered me when dealing with pg_stat_statements contents operating under "track = all" (especially when performing the aggregated analysis, like you showed). I think the idea of having a flag to distinguish the top-level entries is great. > The immediate cons is obviously that it could amplify quite a lot > the number of entries tracked, so people may need to increase > pg_stat_statements.max to avoid slowdown if that makes them reach frequent > entry eviction. > If all top-level records in pg_stat_statements have "true" in the new column (is_toplevel), how would this lead to the need to increase pg_stat_statements.max? The number of records would remain the same, as before extending pg_stat_statements.
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