Subject: Re: pg_stat_statements and "IN" conditions
To: Tom Lane <tgl@sss.pgh.pa.us>, Dmitry Dolgov <9erthalion6@gmail.com>
Cc: 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>
References: <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>
 <20210930134930.d4vzwhvxhfpk2zxt@localhost>
 <CALNJ-vSJvaJbcXr46JMyWFT5rO3BdaHO2E=xnAbLNDw1cyUJ-A@mail.gmail.com>
 <20210930150957.tz3h3unjyrzatw6e@localhost>
 <4154685.1641337363@sss.pgh.pa.us>
From: "Andrey V. Lepikhov" <a.lepikhov@postgrespro.ru>
Organization: Postgres Professional
Message-ID: <b8721722-a73e-0ee9-6513-425e9c88d92f@postgrespro.ru>
Date: Wed, 5 Jan 2022 09:37:33 +0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <4154685.1641337363@sss.pgh.pa.us>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/b8721722-a73e-0ee9-6513-425e9c88d92f%40postgrespro.ru>
Precedence: bulk

On 1/5/22 4:02 AM, Tom Lane wrote:
> Dmitry Dolgov <9erthalion6@gmail.com> writes:
>> 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).
> 
> I've been saying from day one that pushing the query-hashing code into the
> core was a bad idea, and I think this patch perfectly illustrates why.
> We can debate whether the rules proposed here are good for
> pg_stat_statements or not, but it seems inevitable that they will be a
> disaster for some other consumers of the query hash.  In particular,
> dropping external parameters from the hash seems certain to break
> something for somebody
+1.

In a couple of extensions I use different logic of query jumbling - hash 
value is more stable in some cases than in default implementation. For 
example, it should be stable to permutations in 'FROM' section of a query.
And If anyone subtly changes jumbling logic when the extension is 
active, the instance could get huge performance issues.

Let me suggest, that the core should allow an extension at least to 
detect such interference between extensions. Maybe hook could be 
replaced with callback to allow extension see an queryid with underlying 
generation logic what it expects.

-- 
regards,
Andrey Lepikhov
Postgres Professional