Re: pg_stat_statements and "IN" conditions

On Sat, Feb 04, 2023 at 06:08:41PM +0100, Dmitry Dolgov wrote:
> Here is the rebased version. To adapt to the latest changes, I've marked
> ArrayExpr with custom_query_jumble to implement this functionality, but
> tried to make the actual merge logic relatively independent. Otherwise,
> everything is the same.

I was quickly looking at this patch, so these are rough impressions.

+ bool merged; /* whether or not the location was marked as
+ not contributing to jumble */

This part of the patch is a bit disturbing.. We have node attributes
to track if portions of a node should be ignored or have a location
marked, still this "merged" flag is used as an extension to track if a
location should be done or not. Is that a concept that had better be
controlled via a new node attribute?

+--
+-- Consts merging
+--
+CREATE TABLE test_merge (id int, data int);
+-- IN queries
+-- No merging

Would it be better to split this set of tests into a new file? FWIW,
I have a patch in baking process that refactors a bit the whole,
before being able to extend it so as we have more coverage for
normalized utility queries, as of now the query strings stored by
pg_stat_statements don't reflect that even if the jumbling computation
marks the location of the Const nodes included in utility statements
(partition bounds, queries of COPY, etc.). I should be able to send
that tomorrow, and my guess that you could take advantage of that
even for this thread.
--
Michael