Date: Sat, 26 Mar 2022 18:40:35 +0100
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Zhihong Yu <zyu@yugabyte.com>,
	David Steele <david@pgmasters.net>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	Greg Stark <stark@mit.edu>,
	Pavel Trukhanov <pavel.trukhanov@gmail.com>
Subject: Re: pg_stat_statements and "IN" conditions
Message-ID: <20220326174035.2vwhtof6ow7kib7n@erthalion.local>
References: <20220310163837.pzvr4yntdk33cbkb@ddolgov.remote.csb>
 <655954.1646932319@sss.pgh.pa.us>
 <20220312141030.5panohzsskr4zpkk@erthalion.local>
 <CA+TgmoYG+nL1-3xmejYx-dm__7JMpCaptYkCVernS7wrriHQ+w@mail.gmail.com>
 <20220314145734.x3re4hcr6ukmppwi@ddolgov.remote.csb>
 <CA+Tgmob74W5+Da9a=95sRz2EXA221tMHzJ4tNUH5yWyt5Td5aw@mail.gmail.com>
 <178940.1647271397@sss.pgh.pa.us>
 <20220314153346.6chynq26mcypxaco@ddolgov.remote.csb>
 <180607.1647272303@sss.pgh.pa.us>
 <20220314155150.mgitoto7e5jkqilb@ddolgov.remote.csb>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="5qgietps523nzm32"
Content-Disposition: inline
In-Reply-To: <20220314155150.mgitoto7e5jkqilb@ddolgov.remote.csb>
Archived-At: 
 <https://www.postgresql.org/message-id/20220326174035.2vwhtof6ow7kib7n%40erthalion.local>
Precedence: bulk


--5qgietps523nzm32
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

> On Mon, Mar 14, 2022 at 04:51:50PM +0100, Dmitry Dolgov wrote:
> > On Mon, Mar 14, 2022 at 11:38:23AM -0400, Tom Lane wrote:
> > Dmitry Dolgov <9erthalion6@gmail.com> writes:
> > > On Mon, Mar 14, 2022 at 11:23:17AM -0400, Tom Lane wrote:
> > >> I do find it odd that the proposed patch doesn't cause the *entire*
> > >> list to be skipped over.  That seems like extra complexity and confusion
> > >> to no benefit.
> >
> > > That's a bit surprising for me, I haven't even thought that folks could
> > > think this is an odd behaviour. As I've mentioned above, the original
> > > idea was to give some clues about what was inside the collapsed array,
> > > but if everyone finds it unnecessary I can of course change it.
> >
> > But if what we're doing is skipping over an all-Consts list, then the
> > individual Consts would be elided from the pg_stat_statements entry
> > anyway, no?  All that would remain is information about how many such
> > Consts there were, which is exactly the information you want to drop.
>
> Hm, yes, you're right. I guess I was thinking about this more like about
> shortening some text with ellipsis, but indeed no actual Consts will end
> up in the result anyway. Thanks for clarification, will modify the
> patch!

Here is another iteration. Now the patch doesn't leave any trailing
Consts in the normalized query, and contains more documentation. I hope
it's getting better.

--5qgietps523nzm32
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
	filename="v7-0001-Prevent-jumbling-of-every-element-in-ArrayExpr.patch"