On Mon, Jan 10, 2022 at 03:24:46PM +0500, Andrey Lepikhov wrote: > On 10/1/2022 13:56, Julien Rouhaud wrote: > > > > I don't know the details of that extension, but I think that it should work > > as > > long as you have the constants information in the jumble state, whatever the > > resulting normalized query string is right? > 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). > > 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.
