public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Julien Rouhaud <[email protected]>
Cc: Sami Imseih <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: Christoph Berg <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: ma lz <[email protected]>
Subject: Re: query_id: jumble names of temp tables for better pg_stat_statement UX
Date: Tue, 25 Mar 2025 01:17:22 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <Z-I6c1Bbuo3uJWvw@jrouhaud>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAA5RZ0t4XQ_SANiJ5VfuoKnAuxMaY2ggQWoGKkHo+U2H+Sh-Sw@mail.gmail.com>
<[email protected]>
<CAA5RZ0uNofEXfEfNw3uRN3D3oXkFPQ_s+huLLHMKR_+MCk8RPQ@mail.gmail.com>
<[email protected]>
<CAA5RZ0vKpKEWcJn_UZkQVK=j1EUsXfASo06uWSqizzrwKMx8mQ@mail.gmail.com>
<[email protected]>
<Z-I6c1Bbuo3uJWvw@jrouhaud>
Julien Rouhaud <[email protected]> writes:
> On Tue, Mar 25, 2025 at 12:32:05AM -0400, Tom Lane wrote:
>> 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?
Up to a point, perhaps. If I'm writing some kind of tool that digests
pg_stat_statements results, I think I'm entitled to disregard the
possibility that somebody is using a custom query_id that behaves in
ways I'm not expecting --- or at least, fixing my code for that is
their problem not mine. But it's much harder to take that attitude
for things that are built into core PG.
>> 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.
> 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.
Fully agreed. (Even SUSET is debatable in this situation, but I'm okay
with it on the principle that superusers are expected to know what
they're doing and accept the consequences.)
regards, tom lane
view thread (19+ messages) latest in thread
reply
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: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: query_id: jumble names of temp tables for better pg_stat_statement UX
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox