Re: pg_stat_statements oddity with track = all - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: pg_stat_statements oddity with track = all
Date
Msg-id CABUevEzE9+JVMsBZzDBn235MrnkZZXaepDq0_FCudsScd5nbGg@mail.gmail.com
Whole thread Raw
In response to Re: pg_stat_statements oddity with track = all  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: pg_stat_statements oddity with track = all
List pgsql-hackers
On Thu, Apr 8, 2021 at 2:04 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
>
> 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.

I actually thought I looked at that, but clearly I was confused one
way or another.

I think you're right, it's cleaner to merge it into 1.9, so applied and pushed.

-- 
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: TRUNCATE on foreign table
Next
From: Julien Rouhaud
Date:
Subject: Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?