Re: proposal - queryid can be used as filter for auto_explain - Mailing list pgsql-hackers

Hello,

At Wed, 1 Jul 2026 21:51:30 +0200, Pavel Stehule <pavel.stehule@gmail.com> wrote in
> > Separately from that, I don't think auto_explain should enable query
> > ID calculation when it is not actually going to use it. Instead, I
> > wonder whether this should be done in assign_log_queryids(). This
> > would naturally tie enabling query ID calculation to the state of the
> > GUC, including configuration reloads, as well as session-local use via
> > LOAD, while avoiding enabling it in sessions that never use
> > auto_explain.
> >
>
> This is a hard question - I am not sure if one GUC can force a second GUC.

I think there may be a misunderstanding.

I was not suggesting that one GUC should force another GUC. My point
was about when auto_explain calls EnableQueryId(), not about changing
the value of compute_query_id.

Instead of requesting query ID calculation unconditionally when the
module is loaded, I was wondering whether EnableQueryId() could be
called from assign_log_queryids(), so that auto_explain only requests
query ID calculation when it is actually going to use it.

> Please, check Jakub Wartak comment - I am afraid to raise log when queryid
> is not calculated and queryid_filter is not empty. I am afraid to force
> queryid calculation from assigning_queryids_filter. So the implemented
> design is the last way. Instead forcing queryid calculation in
> queryids_filter assignment is better generally not forcing queryid
> calculation.

I think that is a slightly different issue.

I was not suggesting that queryids_filter itself should force query ID
calculation, nor that we should emit a warning when query ID is not
available.

My point was that, if log_queryids is the option that makes
auto_explain use the query ID, then auto_explain could call
EnableQueryId() when that option is enabled. In that case, the
situation where queryids_filter is set but no query ID is calculated
would not be introduced by this change; if log_queryids is off,
auto_explain is not going to use the query ID anyway.

> > -               if (msec >= auto_explain_log_min_duration)
> > +               if (log_filter && msec >= auto_explain_log_min_duration)
> >
> > I think the overall decision logic for deciding whether to log a plan
> > could be reorganized to avoid unnecessary query ID lookups.
> >
>
> when queryids_filter will be empty, then log_filter will be true.
>
> Anytime, the user can set compute_queryid to OFF. My idea is - it should
> work by default, and when the user doesn't want it, then he can explicitly
> disable it.

Yes, that behavior makes sense. I was not suggesting changing the
meaning of an empty queryids_filter.

My comment was about the ordering of the checks in the proposed patch.
If queryids_filter is empty, no query ID lookup is needed to decide
whether the query passes the filter. Likewise, if the duration check
fails, the filter result does not matter. So I was wondering whether
the decision logic could be arranged to avoid query ID lookups in
those cases.

Regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center