On Fri, Mar 19, 2021 at 02:54:16PM +0100, Hannu Krosing wrote: > On Fri, Mar 19, 2021 at 2:29 PM Bruce Momjian <br...@momjian.us> wrote: > > > > OK, that makes perfect sense. I think the best solution is to document > > that compute_query_id just controls the built-in computation of the > > query id, and that extensions can also compute it if this is off, and > > pg_stat_activity and log_line_prefix will display built-in or extension > > computed query ids. > > > > It might be interesting someday to check if the hook changed a > > pre-computed query id and warn the user in the logs, but that could > > cause more log-spam problems than help. > > The log-spam could be mitigated by logging it just once per connection > the first time it is overridden
Yes, but it might still generate a significant amount of additional lines. If extensions authors follow the recommendations and only calculate a queryid when compute_query_id is off, it shoule be easy to check that you have everything setup properly. > Also, we could ask the extensions to expose the "method name" in a read-only > GUC > > so one can do > > SHOW compute_query_id_method; > > and get the name of method use > > compute_query_id_method > ------------------------------------ > builtin > > And it may even dynamically change to indicate the overriding of builtin > > compute_query_id_method > --------------------------------------------------- > fancy_compute_query_id (overrides builtin) This could be nice, but I'm not sure that it would work well if someones install multiple extensions that calculate a queryid (which would be silly but still), or load another one at runtime.