Feedback-ID: i0fe9450f:Fastmail
Date: Tue, 25 Mar 2025 12:53:22 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Sami Imseih <samimseih@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Christoph Berg <myon@debian.org>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
	ma lz <ma100@hotmail.com>
Subject: Re: query_id: jumble names of temp tables for better
 pg_stat_statement UX
Message-ID: <Z-Iosks2FMcHddql@paquier.xyz>
References: <1831838.1742656359@sss.pgh.pa.us>
 <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="WM0exh/zQRLPOcXD"
Content-Disposition: inline
In-Reply-To: <CAA5RZ0vKpKEWcJn_UZkQVK=j1EUsXfASo06uWSqizzrwKMx8mQ@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/Z-Iosks2FMcHddql%40paquier.xyz>
Precedence: bulk


--WM0exh/zQRLPOcXD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 24, 2025 at 10:30:59PM -0500, Sami Imseih wrote:
>> Sami Imseih <samimseih@gmail.com> writes:
>>> I agree that some may want stats to merge for the same tables,
>>> and others may not. I will suggest this with some hesitation, but why n=
ot
>>> make this behavior configurable via a GUC?
>>> We recently introduced query_id_squash_values for controlling
>>> the merge of an IN list, maybe this is another queryId behavior we shou=
ld
>>> provide a configuration for?
>>
>> I don't like that GUC and I would not like this one either.  We
>> learned years ago that GUCs that change query semantics are a bad
>> idea, but apparently now we have hackers who need to relearn that
>> lesson the hard way.  (Admittedly, this isn't quite *query* semantics,
>> which perhaps lessens the blast radius.  But I think we're still going
>> to regret query_id_squash_values.)
>=20
> query_id_squash_values has a much weaker argument to exist than a
> guc to control the use of alias vs OID. Why would anyone not want
> to squash the IN list? maybe we should revisit this decision in that thre=
ad.

This part of the thread is digressing, but I'd on the side of removing
entirely the GUC and make the grouping of IN values the default.  We
still have time to discuss that during the beta cycle, so let's do so
on its related thread.
--
Michael

--WM0exh/zQRLPOcXD
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmfiKLIACgkQnvQgOdby
QH0Ung//dyJvRLneL9QyVqSKSdmewo9qfH9UlvURk1TeOGr0PnZ6D8cL1+AibOuw
8xtQ5O7pZPktQOtApGfIbq3qIQQ8ycKHO1rTwmgAzKIZ/lw3vbHLY0Z0lyUFQUUm
IdFIm1cIQIiAwx71uUM1BADEkbvigOvZldocW1fru11VWIlllGxiTBCQfirXGTOZ
yA71RAt/P/TVNMIuHg9Ky2K45BnhRADR+PnRHaRXZTQ2g6t0kb7P902aOTqFHskw
ccaxVjzogLVDwI/niSW5le2dBpeo012JdTcr++WxYF+NjMW+OsgD18c9QDS5vhNL
TJSuNdIZr5s8xJuoI2lLTy1MNA8Jjf06DVWqvUpq2g5qs/9Rh+nmA2LqyDUEi5WE
wxatq1xcQtw869wfkYRdpWuS7JpQcvvOZ7TxJ8I7ygUg8l2TKaRFdTjKzurfHU3A
mVfgGFL9LlpyWlHBKGtLV7wsGM4leHPZPQaQJ1WMIxv5EVexjDIEcUHIZ1aHxJDb
W8SaNBxsfw0jQ+kno9S+bAN4DyJXzsHePG1NxiWWKUO8NKj+QHRw1RYmJUu2QJsZ
EODInOwr95+k9R/CqHYO6G8diJmwW/n9STdjoIFfgqqrjmR1TgwzBjZpSBS0joW4
slKOblQ8c4/TVMznQgHqF3P5NuO/5NMlyEwFs5lor/TDNxBirFY=
=jLGI
-----END PGP SIGNATURE-----

--WM0exh/zQRLPOcXD--