Thread

Re: pg_stat_statements and "IN" conditions

Julien Rouhaud <rjuju123@gmail.com> — 2025-02-14T14:39:45Z

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.