MIME-Version: 1.0
References: <Z5cDQJM9nnoXuStO@paquier.xyz> <Z5xTb5iBHVGns35R@paquier.xyz>
 <CAP53Pkw1QJHH9UDjkArS=XdAxtK7XWMpZLGHnVMDmhRTp_HYYw@mail.gmail.com>
 <Z5xgmgyV-wnzMpkO@paquier.xyz>
 <CAA5RZ0vM9AsEqvKued2drKZJ1opt3wbYaDbxGzi-khkNzwn7og@mail.gmail.com>
 <Z6Ks3ta5089DXiPc@paquier.xyz>
 <CAA5RZ0sfRbd1xcq_oHNA0TPr57yM8qkg-GoD6A0nUfyxZhs33Q@mail.gmail.com>
 <CAP53PkxocbNr+eRag3FEJp3-7S1U80FspOg8UQjO902TWMG=6A@mail.gmail.com>
 <CAA5RZ0u6yJdFL=p5vdpbZFS-2YY+Z6vtzmt4gejgZa3RcNiWMQ@mail.gmail.com>
 <404111766672953@mail.360.yandex.ru> <aU3CVSkKiyLwfreT@paquier.xyz>
In-Reply-To: <aU3CVSkKiyLwfreT@paquier.xyz>
From: Lukas Fittl <lukas@fittl.com>
Date: Thu, 19 Mar 2026 00:15:07 -0700
Message-ID: 
 <CAP53PkyOB4kbYDoMXQaaN68rkU-Gt_Jw9iNzOgSwM4ULW-QrdQ@mail.gmail.com>
Subject: Re: [PATCH] Optionally record Plan IDs to track plan changes for a
 query
To: Michael Paquier <michael@paquier.xyz>
Cc: =?UTF-8?B?0JDQvdC00YDQtdC5INCa0LDQt9Cw0YfQutC+0LI=?=
 <andrey.kazachkov@tantorlabs.ru>,
	Sami Imseih <samimseih@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Marko M <marko@pganalyze.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAP53PkyOB4kbYDoMXQaaN68rkU-Gt_Jw9iNzOgSwM4ULW-QrdQ%40mail.gmail.com>
Precedence: bulk

On Thu, Dec 25, 2025 at 3:02=E2=80=AFPM Michael Paquier <michael@paquier.xy=
z> wrote:
> +    /*
> +     * COMPUTE_PLAN_ID_REGRESS means COMPUTE_PLAN_ID_YES, but we don't s=
how
> +     * the queryid in any of the EXPLAIN plans to keep stable the result=
s
> +     * generated by regression test suites.
> +     */
> +    if (es->verbose && queryDesc->plannedstmt->planId !=3D UINT64CONST(0=
) &&
> +        compute_plan_id !=3D COMPUTE_PLAN_ID_REGRESS)
> +    {
> +        /*
> +         * Output the queryid as an int64 rather than a uint64 so we mat=
ch
> +         * what would be seen in the BIGINT pg_stat_activity.plan_id col=
umn.
> +         */
> +        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