Hi, On Sat, Jan 29, 2022 at 06:12:05PM +0100, Dmitry Dolgov wrote: > > On Sat, Jan 29, 2022 at 03:51:33PM +0800, Julien Rouhaud wrote: > > > > I'm also unsure of how are extensions supposed to cooperate in general, as > > I feel that queryids should be implemented for some "intent" (like > > monitoring, > > planning optimization...). That being said I'm not sure if e.g. AQO > > heuristics > > are too specific for its need or if it could be shared with other extension > > that might be dealing with similar concerns. > > Assuming there are multiple providers and consumers of queryIds, every > such consumer extension needs to know which type of queryId it wants to > use. E.g. in case of pg_stat_statements, it needs to be somehow > configured to know which of those kinds to take, to preserve > extensibility you're talking about. Does the answer make sense, or did > you mean something else?
I guess, but I don't think that the proposed approach does that. The DBA should be able to configure a monitoring queryid provider, a planning queryid provider... and the extensions should have a way to know which is which. And also I don't think that the DBA should be allowed to setup multiple monitoring queryid providers, nor change them dynamically. > Btw, the approach in this thread still doesn't give a clue what to do > when an extension needs to reuse some parts of core queryId generator, > as in case with pg_stat_statements and "IN" condition merging. Indeed, as the query text normalization is not extensible.
