Feedback-ID: i0fe9450f:Fastmail
Date: Fri, 13 Oct 2023 17:07:00 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
	"Gregory Stark (as CFM)" <stark.cfm@gmail.com>,
	David Geier <geidav.pg@gmail.com>, Sergei Kornilov <sk@zsrv.org>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>,
	Marcos Pegoraro <marcos@f10.com.br>,
	vignesh C <vignesh21@gmail.com>,
	Robert Haas <robertmhaas@gmail.com>, Zhihong Yu <zyu@yugabyte.com>,
	David Steele <david@pgmasters.net>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	Pavel Trukhanov <pavel.trukhanov@gmail.com>,
	Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: pg_stat_statements and "IN" conditions
Message-ID: <ZSj6pOwUCM-Mnh__@paquier.xyz>
References: <20230211120820.y7krq37jubnjsa5b@erthalion.local>
 <07919318-6c35-a13f-6a1d-98686a3e38de@gmail.com>
 <20230217154602.uf3a3cgqeoeysycz@erthalion.local>
 <8702fa3e-5aac-dcf0-161b-faa2b9eadad6@gmail.com>
 <20230226104619.jfmwrpd5zrkmp3eu@erthalion.local>
 <CAM-w4HO29FpoX5oYR7tuxP9sZA1s3zLV94c_79h_uQeNHUjhyQ@mail.gmail.com>
 <20230314190432.l4oe3wa3pvt5b7hx@erthalion.local>
 <20230319122734.xkba536kut3g4gcy@erthalion.local>
 <20230704044611.GA3373000@nathanxps13>
 <20230704190256.arszjcwvrjekxj25@ddolgov.remote.csb>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="/8ZUOu6JSGR8+AYR"
Content-Disposition: inline
In-Reply-To: <20230704190256.arszjcwvrjekxj25@ddolgov.remote.csb>
Archived-At: <https://www.postgresql.org/message-id/ZSj6pOwUCM-Mnh__%40paquier.xyz>
Precedence: bulk


--/8ZUOu6JSGR8+AYR
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 04, 2023 at 09:02:56PM +0200, Dmitry Dolgov wrote:
> On Mon, Jul 03, 2023 at 09:46:11PM -0700, Nathan Bossart wrote:
>> IMHO this adds way too much complexity to something that most users would
>> expect to be an on/off switch.
>=20
> This documentation is exclusively to be precise about how does it work.
> Users don't have to worry about all this, and pretty much turn it
> on/off, as you've described. I agree though, I could probably write this
> text a bit differently.

FWIW, I am going to side with Nathan on this one, but not completely
either.  I was looking at the patch and it brings too much complexity
for a monitoring feature in this code path.  In my experience, I've
seen people complain about IN/ANY never strimmed down to a single
parameter in pg_stat_statements but I still have to hear from somebody
outside this thread that they'd like to reduce an IN clause depending
on the number of items, or something else.

>> If I understand =C1lvaro's suggestion [0] correctly, he's saying that in
>> addition to allowing "on" and "off", it might be worth allowing
>> something like "powers" to yield roughly the behavior described above.
>> I don't think he's suggesting that this "powers" behavior should be
>> the only available option.
>=20
> Independently of what =C1lvaro was suggesting, I find the "powers"
> approach more suitable, because it answers my own concerns about the
> previous implementation. Having "on"/"off" values means we would have to
> scratch heads coming up with a one-size-fit-all default value, or to
> introduce another option for the actual cut-off threshold. I would like
> to avoid both of those options, that's why I went with "powers" only.

Now, it doesn't mean that this approach with the "powers" will never
happen, but based on the set of opinions I am gathering on this thread
I would suggest to rework the patch as follows:
- First implement an on/off switch that reduces the lists in IN and/or
ANY to one parameter.  Simply.
- Second, refactor the powers routine.
- Third, extend the on/off switch, or just implement a threshold with
a second switch.

When it comes to my opinion, I am not seeing any objections to the
feature as a whole, and I'm OK with the first step.  I'm also OK to
keep the door open for more improvements in controlling how these
IN/ANY lists show up, but there could be more than just the number of
items as parameter (say the query size, different behaviors depending
on the number of clauses in queries, subquery context or CTEs/WITH,
etc. just to name a few things coming in mind).
--
Michael

--/8ZUOu6JSGR8+AYR
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmUo+qQACgkQnvQgOdby
QH13UA//RfPiYtzPT5lfjKPnOymR8G94HVwQ6YtBNAkyfe8qCBmlSzq5i4O4umcd
niidHIACLOwnkJNpz8ephG8v4pb6juAXHfKgdrkiJ0AeAbVsH6B9gxb/toV+d6Rm
+KRqWyQTVHXIzsnMh8p8EvcD5dpA4T8GnrM1kGgkR9vCUDJnlPHe37jffzcnaV37
jmPGESm8JYUvPmOpQDSWX8tnmVM44TZIh4xuF7dT+Sg3YMGLApePjHhV2K84+pcf
IrC+uTnItdPJpH5JrDvfFFSJCcM59YD9s1rKyMl4l+AKs+hQjDyHDL+el5zFgrs0
RFoWsl3/LN5wvD44WBzwcpWo7DjbL/8VLHAtA46Jb9wFrdtHktsNHCgD2VyxFShN
dJy6xO2iD4dt1lLQvtGe2aGnlsnuS5JQPuZV3C4G+qxLTCV7VOYIh1ffxHAUAdN9
WUEuw+nwVk2S7vqAto20AyLJu/Ae6wnpmBhRIEZb3466GiaZO6Xw6RPpAYFnBTRi
hSaPsKkFNI75bAVzMfSL6LBq0dUxE/5nmRp1FXHvVo0u6jYWpNtS4zWWVQ/wp1u3
L69ntxgPcWbCdL+P+zMVL6/FcAIXtDgXyB0RZbFOUptKDFfesG2wTWvg0mZn4+sL
YBLfXFU1Mqw2Iq/Ci3ln4FY9ilaj8iGo0Dq1lzmK6wGABpEI9Eo=
=mtMT
-----END PGP SIGNATURE-----

--/8ZUOu6JSGR8+AYR--