Hi, On Fri, Feb 14, 2025 at 09:36:08AM +0100, Dmitry Dolgov wrote: > > On Thu, Feb 13, 2025 at 05:08:45PM GMT, Sami Imseih wrote: > > 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.
While talking about the normalized query text with this patch, I see that merged values are now represented like this, per the regression tests files: +SELECT query, calls FROM pg_stat_statements ORDER BY query COLLATE "C"; + query | calls +------------------------------------------------------+------- + SELECT * FROM test_merge_numeric WHERE data IN (...) | 1 + SELECT pg_stat_statements_reset() IS NOT NULL AS t | 1 +(2 rows) This was probably ok a few years back but pg 16 introduced a new GENERIC_PLAN option for EXPLAIN (3c05284d83b2) to be able to run EXPLAIN on a query extracted from pg_stat_statements (among other things). This feature would break the use case. Note that this is not a hypothetical need: I get very frequent reports on the PoWA project about the impossibility to get an EXPLAIN (we do have some code that tries to reinject the parameters from stored quals but we cannot always do it) that is used with the automatic index suggestion, and we planned to rely on EXPLAIN (GENERIC_PLAN) to have an always working solution. I suspect that other projects also rely on this option for similar features. Since the merging is a yes/no option (I think there used to be some discussions about having a threshold or some other fancy modes), maybe you could instead differentiate the merged version by have 2 constants rather than this "..." or something like that?
