Re: pg_stat_statements and "IN" conditions

On Fri, Feb 14, 2025 at 03:20:24PM +0100, Dmitry Dolgov wrote:
>
> Btw, there was another mistake in the last version introducing
> "$1 /*, ... */" format, the constant position has to be of course
> calculated as usual.

I'm not sure what you mean here, but just in case:

> +SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9) AND data = 2;
> + id | data
> +----+------
> +(0 rows)
> +
> +SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) AND data = 2;
> + id | data
> +----+------
> +(0 rows)
> +
> +SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11) AND data = 2;
> + id | data
> +----+------
> +(0 rows)
> +
> +SELECT query, calls FROM pg_stat_statements ORDER BY query COLLATE "C";
> + query | calls
> +--------------------------------------------------------------------+-------
> + SELECT * FROM test_merge WHERE id IN ($1 /*, ... */) AND data = $3 | 3
> + SELECT pg_stat_statements_reset() IS NOT NULL AS t | 1
> +(2 rows)

There seems to be an off-by-1 error in parameter numbering when merging them.

Note that the query text as-is can still be successfully be used in an EXPLAIN
(GENERIC_PLAN), but it might cause problem to third party tools that try to do
something smarter about the parameters.