Re: pg_stat_statements and "IN" conditions

On 1/5/22 4:02 AM, Tom Lane wrote:
> Dmitry Dolgov <9erthalion6(at)gmail(dot)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