Hello Horiguchi-san, On Wed, May 12, 2021 at 11:08:36AM +0900, Kyotaro Horiguchi wrote: > > If we look it in pg_settings, it shows the current value and the value > at boot-time. So I'm fine with that behavior. > > However, IMHO, I doubt the necessity of "on". Assuming that we require > any module that wants query-id to call queryIdWanted() at any time > after each process startup (or it could be inherited to children), I > think only "auto" and "off" are enough for the variable.
I don't think that this approach would cope well for people who want a queryid without pg_stat_statements or such. Since the queryid can now be found in pg_stat_activity, EXPLAIN output or the logs I think it's entirely reasonable to allow users to benefit from that even if they don't install additional module. > Thinking in > this line, the variable is a subset of a GUC variable to specify the > name of a query-id provider (as Andres suggested upthread), and I > think it would work better in future. > > So for now I propose that we have a variable query_id_provider that > has only 'default' and 'none' as the domain. I think this would be a mistake to do that, as it would mean that we don't officially support alternative queryid provider. > We can later expand it > so that any other query-id provider modules can be loaded without > chaning the interface. The GUC itself may not change, but third-party queryid provider would probably need changes as the new entry point will be dedicated to compute a queryid only, while third-party plugins may do more than that in their post_parse_analyze_hook. And also users will have to change their configuration to use that new interface, and additionally the module may now have to be removed from shared_preload_libraries. Overall, it doesn't seem to me that it would make users' life easier.
