Re: [PATCH] Optionally record Plan IDs to track plan changes for a query

On Thu, Dec 25, 2025 at 3:02 PM Michael Paquier <michael(at)paquier(dot)xyz> 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