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