public inbox for [email protected]
help / color / mirror / Atom feedFrom: Julien Rouhaud <[email protected]>
To: Dmitry Dolgov <[email protected]>
Cc: Sami Imseih <[email protected]>
Cc: Álvaro Herrera <[email protected]>
Cc: Kirill Reshke <[email protected]>
Cc: Sergei Kornilov <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: Sutou Kouhei <[email protected]>
Subject: Re: pg_stat_statements and "IN" conditions
Date: Fri, 14 Feb 2025 17:28:20 +0800
Message-ID: <Z68MtDCGVZi-Qqry@jrouhaud> (raw)
In-Reply-To: <blauoky77sash2qzrbnz6ilfyi7odtvxtdr4ifg4hq4bpqp2uk@6z5yjfsxtcnl>
References: <qvotbnl7ycigw3txl5kcbts4nxycucggnixmfqidlfmx3nnpjw@dxw6duw35dno>
<[email protected]>
<z7daminuuasjjunvhul5q5zwvjjrkvkldizq6oriufxnjvq6l5@6tgsib66vp7c>
<CAA5RZ0uGfxXyzhp9N5nfsS+ZqF5ngEMC3YtBPtLoeK8EPsjHbw@mail.gmail.com>
<blauoky77sash2qzrbnz6ilfyi7odtvxtdr4ifg4hq4bpqp2uk@6z5yjfsxtcnl>
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?
view thread (7+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: pg_stat_statements and "IN" conditions
In-Reply-To: <Z68MtDCGVZi-Qqry@jrouhaud>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox