Date: Tue, 14 Mar 2023 20:04:32 +0100
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: "Gregory Stark (as CFM)" <stark.cfm@gmail.com>
Cc: David Geier <geidav.pg@gmail.com>, Sergei Kornilov <sk@zsrv.org>,
	Michael Paquier <michael@paquier.xyz>,
	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: <20230314190432.l4oe3wa3pvt5b7hx@erthalion.local>
References: <966631675800892@znolar4klagewshm.sas.yp-c.yandex.net>
 <20230209150238.rdtwruh5i34hdag5@ddolgov.remote.csb>
 <dda65b89-4ebf-261c-de9c-7b91ab9e4047@gmail.com>
 <20230211104707.grsicemegr7d3mgh@erthalion.local>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAM-w4HO29FpoX5oYR7tuxP9sZA1s3zLV94c_79h_uQeNHUjhyQ@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/20230314190432.l4oe3wa3pvt5b7hx%40erthalion.local>
Precedence: bulk

> On Tue, Mar 14, 2023 at 02:14:17PM -0400, Gregory Stark (as CFM) wrote:
> So I was seeing that this patch needs a rebase according to cfbot.

Yeah, folks are getting up to speed in with pgss improvements recently.
Thanks for letting me know.

> However it looks like the review feedback you're looking for is more
> of design questions. What jumbling is best to include in the feature
> set and which is best to add in later patches. It sounds like you've
> gotten conflicting feedback from initial reviews.
>
> It does sound like the patch is pretty mature and you're actively
> responding to feedback so if you got more authoritative feedback it
> might even be committable now. It's already been two years of being
> rolled forward so it would be a shame to keep rolling it forward.

You got it about right. There is a balance to strike between
implementation, that would cover more useful cases, but has more
dependencies (something like possibility of having multiple query id),
and more minimalistic implementation that would actually be acceptable
in the way it is now. But I haven't heard back from David about it, so I
assume everybody is fine with the minimalistic approach.

> Or is there some fatal problem that you're trying to work around and
> still haven't found the magic combination that convinces any
> committers this is something we want? In which case perhaps we set
> this patch returned? I don't get that impression myself though.

Nothing like this on my side, although I'm not good at conjuring
committing powers of the nature.