On Thu, Dec 25, 2025 at 05:33:11PM +0300, Андрей Казачков wrote:
> I’ve been testing the proposed v5 plan id work and found out instability of
> computing the plan identifier after feeding different query texts that
> produces the same physical plan trees but with different plan ids. The main
> pattern regards with fields of Plan node structures that depend on positions of
> RTEs in a RTE list.
FWIW, I don't think that we have a clear agreement about what would be
a good enough ID for plan trees, as it may be also a per-vendor
computation that fills specific user requirements.
+ /*
+ * COMPUTE_PLAN_ID_REGRESS means COMPUTE_PLAN_ID_YES, but we don't show
+ * the queryid in any of the EXPLAIN plans to keep stable the results
+ * generated by regression test suites.
+ */
+ if (es->verbose && queryDesc->plannedstmt->planId != UINT64CONST(0) &&
+ compute_plan_id != COMPUTE_PLAN_ID_REGRESS)
+ {
+ /*
+ * Output the queryid as an int64 rather than a uint64 so we match
+ * what would be seen in the BIGINT pg_stat_activity.plan_id column.
+ */
+ ExplainPropertyInteger("Plan Identifier", NULL,
+ queryDesc->plannedstmt->planId, es);
+ }
Now, looking at this block of code, I am wondering if you don't have a
point here even without compute_plan_id.. Could there be merit in
showing this information for an EXPLAIN if this field is not zero?
With EXPLAIN being pluggable in a hook, I doubt that it matters much,
but I am wondering if providing this information could make the work
of some extensions easier.
--
Michael
