Date: Fri, 13 Oct 2023 15:35:19 +0200
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
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: <20231013133519.yf26oncodrvemfjw@ddolgov.remote.csb>
References: <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>
 <ZSj6pOwUCM-Mnh__@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZSj6pOwUCM-Mnh__@paquier.xyz>
Archived-At: <https://www.postgresql.org/message-id/20231013133519.yf26oncodrvemfjw%40ddolgov.remote.csb>
Precedence: bulk

> On Fri, Oct 13, 2023 at 05:07:00PM +0900, Michael Paquier wrote:
> 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.

Well, if it will help move this patch forward, why not. To clarify, I'm
going to split the current implementation into three patches, one for
each point you've mentioned.

> 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).

Interesting point, but now it's my turn to have troubles imagining the
case, where list representation could be controlled depending on
something else than the number of elements in it. Do you have any
specific example in mind?