On Fri, Mar 19, 2021 at 02:54:16PM +0100, Hannu Krosing wrote:
> On Fri, Mar 19, 2021 at 2:29 PM Bruce Momjian <bruce@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.
