On Fri, Feb 14, 2025 at 03:56:32PM +0100, Dmitry Dolgov wrote: > > On Fri, Feb 14, 2025 at 10:39:45PM GMT, Julien Rouhaud wrote: > > There seems to be an off-by-1 error in parameter numbering when merging > > them. > > There are indeed three constants, but the second is not visible in the > query text. Maybe makes sense to adjust the number in this case, let me > try.
Thanks! > > > 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. > > Since the normalized query will be a valid one now, I hope that such > cases will be rare. On top of that it always will be option to not > enable constants squashing and avoid any troubles. It might not always be an option. I have seen application that create thousands of duplicated queryids just because they have a non deterministic amount of parameters they put in such IN () clauses. If that leads to a total number of unique (dbid, userid, queryid, toplevel) too big for a reasonable pg_stat_statements.max, they the only choice might be to enable the new merging parameter or deactivating pg_stat_statements. > Or do you have some > particular scenario of what might be problematic? I don't have a very specific scenario. It's mostly for things like trying to "un-jumble" a query, you may need to loop through the parameters and a missing number could be problematic. But since the overall number of parameters might change from execution to execution that's probably the least of the problems to deal with with this merging feature.
