Date: Thu, 30 Sep 2021 15:49:30 +0200
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: David Steele <david@pgmasters.net>
Cc: Zhihong Yu <zyu@yugabyte.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	Tom Lane <tgl@sss.pgh.pa.us>, Greg Stark <stark@mit.edu>,
	Pavel Trukhanov <pavel.trukhanov@gmail.com>
Subject: Re: pg_stat_statements and "IN" conditions
Message-ID: <20210930134930.d4vzwhvxhfpk2zxt@localhost>
References: 
 <CA+q6zcWtUbT_Sxj0V6HY6EZ89uv5wuG5aefpe_9n0Jr3VwntFg@mail.gmail.com>
 <20201118160432.hyko73sqc2bf7nkj@localhost>
 <20201226104635.uvzkftzu72zg5qux@localhost>
 <CALNJ-vQx7u-Nq_wVun72CVrHe4DcGfEurj_ikckJrRy2Pem=JA@mail.gmail.com>
 <20210105125230.etgmgixnn6fmpszl@localhost>
 <CALNJ-vRRrdXu9igzh5PFTBghK5hnQWF6gpntTPo_+Agq_TsT5Q@mail.gmail.com>
 <ec47aa60-0a7b-ea3a-222a-5c6a754c2def@pgmasters.net>
 <20210318155002.ggrgf2p2mvaodcox@localhost>
 <20210615151850.6nsue7z5xjhpytle@localhost>
 <20210616140212.kt3n5wi3alfz5i5d@localhost>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="mapvsyiflabcgyvj"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20210616140212.kt3n5wi3alfz5i5d@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/20210930134930.d4vzwhvxhfpk2zxt%40localhost>
Precedence: bulk


--mapvsyiflabcgyvj
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

>On Wed, Jun 16, 2021 at 04:02:12PM +0200, Dmitry Dolgov wrote:
>
> > I've prepared a new rebased version to deal with the new way of
> > computing query id, but as always there is one tricky part. From what I
> > understand, now an external module can provide custom implementation for
> > query id computation algorithm. It seems natural to think this machinery
> > could be used instead of patch in the thread, i.e. one could create a
> > custom logic that will enable constants collapsing as needed, so that
> > same queries with different number of constants in an array will be
> > hashed into the same record.
> >
> > But there is a limitation in how such queries will be normalized
> > afterwards — to reduce level of surprise it's necessary to display the
> > fact that a certain query in fact had more constants that are showed in
> > pgss record. Ideally LocationLen needs to carry some bits of information
> > on what exactly could be skipped, and generate_normalized_query needs to
> > understand that, both are not reachable for an external module with
> > custom query id logic (without replicating significant part of the
> > existing code). Hence, a new version of the patch.
>
> Forgot to mention a couple of people who already reviewed the patch.

And now for something completely different, here is a new patch version.
It contains a small fix for one problem we've found during testing (one
path code was incorrectly assuming find_const_walker results).

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