Thread

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

Michael Paquier <michael@paquier.xyz> — 2025-12-25T23:01:41Z

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