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.
