On Mon, Jan 10, 2022 at 12:37:34PM +0500, Andrey V. Lepikhov wrote: > I think, pg_stat_statements can live with an queryId generator of the > sr_plan extension. But It replaces all constants with $XXX parameter at the > query string. In our extension user defines which plan is optimal and which > constants can be used as parameters in the plan.
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? > One drawback I see here - creating or dropping of my extension changes > behavior of pg_stat_statements that leads to distortion of the DB load > profile. Also, we haven't guarantees, that another extension will work > correctly (or in optimal way) with such queryId. 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?
