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

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: pavel(dot)stehule(at)gmail(dot)com
Cc: zsolt(dot)parragi(at)percona(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: proposal - queryid can be used as filter for auto_explain
Date: 2026-07-01 02:30:26
Message-ID: 20260701.113026.1187278169059229298.horikyota.ntt@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello, I have a few comments on this.

+ /*
+ * Inform the postmaster that we want to enable query_id calculation if
+ * compute_query_id is set to auto.
+ */
+ EnableQueryId();

This comment is not entirely accurate because when the module is
loaded using LOAD, the setting is enabled only for the current
session, not in the postmaster.

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.

+ if (queryId != INT64CONST(0))
+ {
+ int i;
+
...
+ for (i = 0; i < queryId_filter->nqueryids; i++)
+ {

I think it would be better to write this as "for (int i = ...".

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

+ /*
+ * We expect small number of watched queryids, and then
+ * a linear seaching is the fastest. As an alternative
+ * we can sort the array of queryId, and we can search
+ * there by bisection.
+ */

I also think a linear search is fine here. If this ever turns out to
be insufficient, I expect we'd simply switch to a more appropriate
algorithm, regardless of whether the alternatives are mentioned here
or not. Also, "is the fastest" seems stronger than necessary. I think
we usually write comments like:

> We expect only a few watched query IDs, so a linear search is sufficient.

+ if (log_filter && msec >= auto_explain_log_min_duration)

This part made me pause because the relationship between log_filter
and log_min_duration is not immediately obvious.

Initially, I assumed they were independent options, so I expected an
OR relationship. However, the implementation uses AND. If users also
assume these are independent settings, the behavior may be
surprising. Perhaps it would make sense to introduce a separate
log_queryid_min_duration parameter if these are intended to be
independent controls.

+ /*
+ * queryid is 64bit integer. strtol fails on 32bit or on MSWin.
+ * In other places, queryid passed (from, to SQL) as generic int8,
+ * so we can use int8in routine. int8in can raise an exception,
+ * so pg_strtoint64_safe is used instead.
+ */

I don't think this comment is necessary. Using pg_strtoint64_safe()
already makes the intent clear.

I also think it would be good to add a test for the LOAD case.

Regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2026-07-01 02:46:39 Re: Include sequences in publications created by pg_createsubscriber
Previous Message John Naylor 2026-07-01 02:19:57 Re: [PATCH] Document wal_compression=on