On Thu, Dec 25, 2025 at 3:02 PM Michael Paquier <[email protected]> wrote: > + /* > + * 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.
I missed this at the time, but happened to run across this by coincidence. Consider this a late +1 on the idea, i.e. I do think that emitting the plan ID as "plan identifier" in EXPLAIN seems reasonable when a plugin sets it - the cost is negligible, and it'd make it easier to work with extensions like pg_stat_plans. Thanks, Lukas -- Lukas Fittl
