Re: [PATCH] Optionally record Plan IDs to track plan changes for a query - Mailing list pgsql-hackers

On Thu, Dec 25, 2025 at 3:02 PM Michael Paquier <michael@paquier.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