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

Hi

čt 2. 7. 2026 v 9:04 odesílatel Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
napsal:

> 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.
>

I understand - and the main problem is fact so query ID calculation doesn't
allow more accurate management.

I think so any way is legitime - just depends what is preferred -
robustness or effectivity

There is not any precedent in core - for pg_stat_statements and
pg_stash_advice the queryid is required always.

So I see a few possibilities:

1. EnableQueryId on start - it is the generic most simple solution - in my
experience - it is only safe guard for cases, where auto_explain is used
without pg_stat_statements (which is not too common). Negative impact -
queryid will be calculated although it can be useless (until somebody
explicitly disables it). But it is only in cases where queryid is not
required by another module.

2. Delayed call EnableQueryId - called in GUC assignment - it should work
too. I intuitively dislike it, because it is only a one way switch.

3. Don't call EnableQueryId in auto_explain - we can document - if
log_queryids is used, then compute_queryid should be ON.

4. Introduction of a new API that allows accurate queryid computing
management. Any module can signalize dynamically if a queryid is required.
This needs a deeper discussion.

Please, everybody, what do you prefer?

>
> > > 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.
>

understand - changed

Regards

Pavel

>
> Regards,
>
> --
> Kyotaro Horiguchi
> NTT Open Source Software Center
>