Re: pg_stat_statements and "IN" conditions

> On Thu, Feb 13, 2025 at 05:08:45PM GMT, Sami Imseih wrote:
> Constants passed as parameters to a prepared statement will not be
> handled as expected. I did not not test explicit PREPARE/EXECUTE statement,
> but I assume it will have the same issue.

This is the same question of supporting various cases. The original
patch implementation handled Param expressions as well, this part was
explicitly rejected during review. I think as a first step it's
important to find a balance between applying this optimization in as
many cases as possible, and at the same time keep the implementation
simple to give the patch a chance. So far I'm inclined to leave Param
for the future work, although of course I'm open to discussion.

> This case with an array passed to aa function seems to cause a regression
> in pg_stat_statements query text. As you can see the text is incomplete.

I've already mentioned that in the previous email. To reiterate, it's
not a functionality regression, but an incomplete representation of a
normalized query which turned out to be hard to change. While I'm
working on that, there is a suggestion that it's not a blocker.

> A typo in the docs.
> c/lenght/length

One day I'll write documentation without any typo, but not today :) Thanks,
will fix with the next version.

> Is this parameter specific to only useful to merge the values of an IN list.
> Should the documentation be more specific and say that only IN lists
> will benefit from this parameter?

You can find one test showing that this optimization is applied to a
plain ARRAY[1, 2, 3, ...], so it's not only IN expressions.

> Also, if there is only 1 value in the list, it will have a different
> queryId than
> that of the same query in which more than 1 value is passed to the IN list.
> Should the documentation be clear about that?

I tend to think there is not much value in emphasizing that. It will add more
mental overhead to process, but this part already says "an array of constants
will contribute only the first and the last elements to the query identifier"
-- having only the first element differs from having both, hence a new entry.

> pg_node_attr of query_jumble_merge is doing something
> very specific to the elements list of an ArrayExpr. The
> merge code likely cannot be used for other node types.

It can be, take a look at pg_node_attr commentary. Any node can have a
field marked with query_jumble_merge attribut and benefit from merging.