On Tue, Mar 19, 2019 at 2:45 PM Maksim Milyutin <milyuti...@gmail.com> wrote: > > But I think that enough to integrate into core the query normalization > routine and store generalized query strings (from which the queryId is > produced) in shared memory (for example, hashtable that maps queryId to > the text representation of generalized query).
That's more or less how pg_stat_statements was previously behaving, and it had too many problems. Current implementation, with an external file, is a better alternative. > And activate > normalization routine and filling the table of generalized queries by > specified GUC. > > This allows to unbind extensions that require queryId from using > pg_stat_statements and consider such computing of queryId as canonical. The problem I see with this approach is that if you want a different implementation, you'll have to reimplement the in-core normalised queries saving and retrieval, but with a different set of SQL-visible functions. I don't think that's it's acceptable, unless we add a specific hook for query normalisation and queryid computing. But it isn't ideal either, as it would be a total mess if someone changes the implementation without resetting the previously saved normalised queries.
