Date: Wed, 12 Feb 2025 11:50:47 +0800
From: Julien Rouhaud <rjuju123@gmail.com>
To: Sami Imseih <samimseih@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Lukas Fittl <lukas@fittl.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
	Marko M <marko@pganalyze.com>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>
Subject: Re: [PATCH] Optionally record Plan IDs to track plan changes for a
 query
Message-ID: <Z6wal4gWT4NW6sJv@jrouhaud>
References: <CAA5RZ0sfRbd1xcq_oHNA0TPr57yM8qkg-GoD6A0nUfyxZhs33Q@mail.gmail.com>
 <CAP53PkxocbNr+eRag3FEJp3-7S1U80FspOg8UQjO902TWMG=6A@mail.gmail.com>
 <CAA5RZ0u6yJdFL=p5vdpbZFS-2YY+Z6vtzmt4gejgZa3RcNiWMQ@mail.gmail.com>
 <Z6lVcWdNQtgz9BGI@paquier.xyz>
 <CAA5RZ0t80hP2aTv97QtEJy39GkxKmDBVDiTBApfiuTa4O=TEWQ@mail.gmail.com>
 <Z6vmYBgLRLXkx5fi@paquier.xyz>
 <Z6v3dSJ7yEJ9xai4@jrouhaud>
 <Z6wAaGieBgd0VX_8@paquier.xyz>
 <Z6wF_eCtCjav3hrQ@jrouhaud>
 <CAA5RZ0t19ourU6_dVZ7yLsDkbJ4Bu5iAKHfsb8TVrR2pg-92vg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAA5RZ0t19ourU6_dVZ7yLsDkbJ4Bu5iAKHfsb8TVrR2pg-92vg@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/Z6wal4gWT4NW6sJv%40jrouhaud>
Precedence: bulk

On Tue, Feb 11, 2025 at 08:57:46PM -0600, Sami Imseih wrote:
> > Of course some people may want to keep the current behavior, if they have
> > limited number of temp tables or similar, so I had a GUC for that.  I don't
> > think that the community would really welcome such GUC for core-postgres,
> > especially since it wouldn't be pg_stat_statements specific.
>
> FWIW, I think options to tweak queryId computation is something
> that should be in core. It was discussed earlier in the context
> of IN list merging; the patch for this currently has the guc
> for the feature in pg_stat_statements, but there was a discussion
> about actually moving this to core [1] Giving the user a way
> to control certain behavior about the queryId computation
> is a good thing to do in core; especially queryId is no longer
> just consumed in pg_stat_statements. Maybe the right answer
> is an enum GUC, not sure yet.
>
> Specifically for the use-case you mention, using names vs OIDs in
> queryId computation is a valid use case for more than temporary tables,
> I can also think of upgrade, dump/restore, logical replication cases which
> can then allow for a consistent queryId.

Well, the ability for extensions to override the actual queryid calculation was
the result of more than half a decade of strong disagreements about it.   And
I'm definitely not volunteering to reopen that topic :)