From: Julien Rouhaud <rjuju123@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Sami Imseih <samimseih@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Christoph Berg <myon@debian.org>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: ma lz <ma100@hotmail.com>
Subject: Re: query_id: jumble names of temp tables for better pg_stat_statement UX
Date: Tue, 25 Mar 2025 13:09:07 +0800
Message-ID: <Z-I6c1Bbuo3uJWvw@jrouhaud> (raw)
In-Reply-To: <1203118.1742877125@sss.pgh.pa.us>
References: <80506.1742660683@sss.pgh.pa.us>
<Z99aIy9T0f-lulK5@paquier.xyz>
<461405.1742691859@sss.pgh.pa.us>
<Z9-sUvq8pE5uinEu@paquier.xyz>
<CAA5RZ0t4XQ_SANiJ5VfuoKnAuxMaY2ggQWoGKkHo+U2H+Sh-Sw@mail.gmail.com>
<1189112.1742869660@sss.pgh.pa.us>
<CAA5RZ0uNofEXfEfNw3uRN3D3oXkFPQ_s+huLLHMKR_+MCk8RPQ@mail.gmail.com>
<1192185.1742871390@sss.pgh.pa.us>
<CAA5RZ0vKpKEWcJn_UZkQVK=j1EUsXfASo06uWSqizzrwKMx8mQ@mail.gmail.com>
<1203118.1742877125@sss.pgh.pa.us>
Hi,
On Tue, Mar 25, 2025 at 12:32:05AM -0400, Tom Lane wrote:
>
> I'm not opining one way or the other on whether squashing an IN list
> is desirable. My point is that a GUC is a poor way to make --- or
> really, avoid making --- such decisions. The reasons we took away
> from previous experiments with semantics-determing GUCs were:
>
> 1. The scope of effect of a GUC is seldom what you want for such
> things. There are going to be some queries in which you want behavior
> A, and some in which you want behavior B, and in the worst case you
> want different behaviors in different parts of the same query. It's
> really painful to make that happen.
>
> 2. Tools that are not entitled to set the value of the GUC are forced
> to be prepared to cope with any setting. That can be anywhere from
> painful to impossible.
Didn't that ship already sailed in pg14 when we allowed generating custom
query_id?
Now:
> For the specific context of controlling how query jumbling happens,
> there's still another problem: the actual statement-merging behavior of
> pg_stat_statements will depend on the totality of settings of the GUC
> across the entire system. It's not very clear to me what will happen
> if different sessions use different settings, much less if people
> change the setting intra-session; but I bet a lot of people will find
> it surprising. 62d712ecf did no one any favors by marking that GUC
> USERSET rather than something that would prevail system-wide.
One of the requirement for the custom query_id was that you shouldn't be
allowed to change the algorithm dynamically, at least not unless a superuser
agrees to maybe break everything, which is why compute_query_id is marked as
PGC_SUSET. I think that the same reasoning should apply here and if the GUC is
kept it should be at least at that level.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-general@postgresql.org
Cc: rjuju123@gmail.com, tgl@sss.pgh.pa.us, samimseih@gmail.com, michael@paquier.xyz, myon@debian.org, pgsql-hackers@lists.postgresql.org, ma100@hotmail.com
Subject: Re: query_id: jumble names of temp tables for better pg_stat_statement UX
In-Reply-To: <Z-I6c1Bbuo3uJWvw@jrouhaud>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox