On Fri, Mar 19, 2021 at 09:29:06AM -0400, Bruce Momjian wrote:
> On Fri, Mar 19, 2021 at 11:16:50AM +0800, Julien Rouhaud wrote:
> > Now that I'm back on the code I remember why I did it this way. It's
> > unfortunately not really possible to make things work this way.
> >
> > pg_stat_statements' post_parse_analyze_hook relies on a queryid already being
> > computed, as it's where we know where the constants are recorded. It means:
> >
> > - we have to call post_parse_analyze_hook *after* doing core queryid
> > calculation
> > - if users want to use a third party module to calculate a queryid, they'll
> > have to make sure that the module's post_parse_analyze_hook is called
> > *before* pg_stat_statements' one.
> > - even if they do so, they'll still have to pay the price of core queryid
> > calculation
>
> 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.
So the last version of the patch should implement that behavior right? It's
just missing some explicit guidance that third-party extensions should only
calculate a queryid if compute_query_id is off
> 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. I am a little worried that
> someone might have compute_query_id enabled and then install an
> extension that overwrites it, but we will just have to document this
> issue. Hopefully extensions will be clear that they are computing their
> own query id.
I agree. And hopefully they will split the queryid calculation from the rest
of the extension so that users can use the combination they want.
