On Wed, Mar 17, 2021 at 06:32:16PM -0400, Bruce Momjian wrote:
> On Wed, Mar 17, 2021 at 04:04:44PM -0400, Robert Haas wrote:
> > On Wed, Mar 17, 2021 at 12:48 PM Julien Rouhaud <rjuju...@gmail.com> wrote:
> > > I originally suggested to make it clearer by having an enum GUC rather
> > > than a
> > > boolean, say compute_queryid = [ none | core | external ], and if set to
> > > external then a hook would be explicitely called. Right now, "none" and
> > > "external" are binded with compute_queryid = off, and depends on whether
> > > an
> > > extension is computing a queryid during post_parse_analyse_hook.
> >
> > I would just make it a Boolean and have a hook. The Boolean controls
> > whether it gets computed at all, and the hook lets an external module
> > override the way it gets computed.
>
> OK, is that what everyone wants? I think that is what the patch already
> does.
Note exactly. Right now a custom queryid can be computed even if
compute_queryid is off, if some extension does that in post_parse_analyze_hook.
I'm assuming that what Robert was thinking was more like:
if (compute_queryid)
{
if (queryid_hook)
queryId = queryid_hook(...);
else
queryId = JumbeQuery(...);
}
else
queryId = 0;
And that should be done *after* post_parse_analyse_hook so that it's clear that
this hook is no longer the place to compute queryid.
Is that what should be done?
> I think having multiple queryids used in a single cluster is much too
> confusing to support. You would have to label and control which queryid
> is displayed by pg_stat_activity and log_line_prefix, and that seems too
> confusing and not useful.
I agree.
