| From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
|---|---|
| To: | Magnus Hagander <magnus(at)hagander(dot)net> |
| Cc: | Sergei Kornilov <sk(at)zsrv(dot)org>, legrand legrand <legrand_legrand(at)hotmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_stat_statements oddity with track = all |
| Date: | 2021-04-08 12:05:05 |
| Message-ID: | 20210408120505.7zinijtdexbyghvb@nol |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Don-t-bump-pg_stat_statements-to-1.10-in-REL_14_S.patch | text/x-diff | 8.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2021-04-08 12:05:22 | Re: PostgreSQL 14 Feature Freeze + Release Management Team (RMT) |
| Previous Message | David Rowley | 2021-04-08 12:00:59 | Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays |