Re: proposal - queryid can be used as filter for auto_explain

At Thu, 2 Jul 2026 06:50:21 +0200, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote in
> Unfortunately EnableQueryId is not reversible.
>
> So when users force EnableQueryId by non-empty log_queryids, then can be
> confused
> when trying to set empty log_queryid, but the queryid will be computed
> until the end of session.
>
> If I can switch queryid computing to between on, off, then this can be good
> idea, but becase
> I can only enable computing, then I don't like it too much.

There is also the opposite way of looking at it.

With the current behavior, simply loading auto_explain causes query ID
calculation to be requested, even if the session never intends to use
query IDs. Disabling that requires setting compute_query_id to off,
which also affects other modules. That seems less natural to me than
keeping query ID calculation enabled after log_queryids has been
enabled once in the session.

To me, requesting query ID calculation only when auto_explain is
actually configured to use it better matches the user's expectation,
even if the request itself is not reversible.

Of course, if others still think that enabling query ID calculation at
module load time is the better choice, then I don't have any strong
objection.

> > 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.
> >
>
> do you think some like
>
> if (!queryid_filter || log_filter) && (msec >=
> auto_explain_log_min_duration))
>
> ??

Not quite. My point was that if auto_explain_log_min_duration already
rejects the query, then any query ID lookup is unnecessary.

So I was thinking more along these lines:

if (msec >= auto_explain_log_min_duration)
{
if (queryids_filter_is_empty || queryid_matches_filter())
log_plan();
}

The important part is that queryid_matches_filter() should only be
called after the duration check has passed and only when the filter is
not empty.

The helper function above is just for illustration. I don't mean to
suggest introducing such a function; I'm perfectly fine with keeping the
decision logic open-coded if that fits the existing code better.

Regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center