On Wed, May 12, 2021 at 09:13:25PM -0400, Bruce Momjian wrote: > On Thu, May 13, 2021 at 08:52:36AM +0800, Julien Rouhaud wrote: > > > > Well, as implemented you can get the value of compute_query_id, and if it's > > still "auto" then it's not enabled as calling queryIdWanted() would turn it > > to > > on. I agree that it's not ideal but you have a way to know. We could > > document > > that auto means that it's set to auto and no one asked to automatically > > enabled > > it. > > Wow, so the extension changes it?
Yes. It seemed better to go this way rather than having a secondary read-only GUC for that. > How do we record the "source" of that > change? Do we have other GUCs that do that? No, we don't. But I don't know what exactly you would like to have as a source? What if you have for instance pg_stat_statements, pg_stat_kcache, pg_store_plans and pg_wait_sampling installed? All those extensions need a query_id (or at least benefit from it for pg_wait_sampling), is there any value to give a full list of all the modules that would enable compute_query_id? I'm assuming that anyone wanting to install any of those extensions (or any similar one) is fully aware that they aggregate metrics based on at least a query_id. If they don't, well they probably never read any documentation since postgres 9.2 which introduced query normalization, and I doubt that they will be interested in having access to the information anyway.
