Thread

  1. Re: pg_stat_statements and "IN" conditions

    Julien Rouhaud <rjuju123@gmail.com> — 2025-02-14T09:28:20Z

    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?