On 10/1/2022 15:39, Julien Rouhaud wrote:
On Mon, Jan 10, 2022 at 03:24:46PM +0500, Andrey Lepikhov wrote:
On 10/1/2022 13:56, Julien Rouhaud wrote:
Yes. the same input query string doesn't prove that frozen query plan can be
used, because rewrite rules could be changed. So we use only a query tree.
Yes, I'm fully aware of that. I wasn't asking about using the input query
string but the need for generating a dedicated normalized output query string
that would be potentially different from the one generated by
pg_stat_statements (or similar).
Thanks, now I got it. I don't remember a single situation where we would
need to normalize a query string.
But then, if generating 2 queryid is a better for performance, does the
extension really need an additional jumble state and/or normalized query
string?
Additional Jumble state isn't necessary, but it would be better for
performance to collect pointers to all constant nodes during a process of
hash generation.
I agree, but it's even better for performance if this is collected only once.
I still don't know if this extension (or any extension) would require something
different from a common jumble state that would serve for all purpose or if we
can work with a single jumble state and only handle multiple queryid.
I think, JumbleState in highly monitoring-specific, maybe even
pg_stat_statements specific (maybe you can designate another examples).
I haven't ideas how it can be used in arbitrary extension.
But, it is not so difficult to imagine an implementation (as part of
Tom's approach, described earlier) such kind of storage for each
generation method.
--
regards,
Andrey Lepikhov
Postgres Professional
