Re: pg_stat_statements oddity with track = all
Julien Rouhaud <rjuju123@gmail.com>
From: Julien Rouhaud <rjuju123@gmail.com>
To: Magnus Hagander <magnus@hagander.net>
Cc: Sergei Kornilov <sk@zsrv.org>, legrand legrand <legrand_legrand@hotmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-04-08T12:05:05Z
Lists: pgsql-hackers
Attachments
On Thu, Apr 08, 2021 at 10:30:53AM +0200, Magnus Hagander wrote: > > I agree. If those numbers are indeed representable, it seems like > better to pay that overhead than to pay the overhead of trying to > de-dupe it. > > Let's hope they are :) :) > Looking through ti again my feeling said the toplevel column should go > after the queryid and not before, but I'm not going to open up a > bikeshed over that. > > I've added in a comment to cover that one that you removed (if you did > send an updated patch as you said, then I missed it -- sorry), and > applied the rest. Oops, somehow I totally forgot to send the new patch, sorry :( While looking at the patch, I unfortunately just realize that I unnecessarily bumped the version to 1.10, as 1.9 was already new as of pg14. Honestly I have no idea why I used 1.10 at that time. Version numbers are not a scarce resource but maybe it would be better to keep 1.10 for a future major postgres version? If yes, PFA a patch to merge 1.10 in 1.9.
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