MIME-Version: 1.0
References: 
 <CA+TgmoZ-Jh1T6QyWoCODMVQdhTUPYkaZjWztzP1En4=ZHoKPzw@mail.gmail.com>
 <CA+HiwqEb8ZUfq92TMBNUtetfMV=50mHGTNrt8kOkoE9m_aqZvw@mail.gmail.com>
 <CA+TgmoY0J9==y93stO7QaAU+TyA-zm5wqsc4GWUa0hgzPAi_sw@mail.gmail.com>
 <CADkLM=d0yH-+z4T6SmuAjYvCj5n7PUVTUJVue48Y60yZFwRVhA@mail.gmail.com>
In-Reply-To: 
 <CADkLM=d0yH-+z4T6SmuAjYvCj5n7PUVTUJVue48Y60yZFwRVhA@mail.gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Wed, 10 Dec 2025 16:29:50 -0500
Message-ID: 
 <CA+TgmoZdvRJY62T_OmN1yqdA3qws1znuYq4KVLfMaU+MFaNhbA@mail.gmail.com>
Subject: Re: pg_plan_advice
To: Corey Huinker <corey.huinker@gmail.com>
Cc: Amit Langote <amitlangote09@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BTgmoZdvRJY62T_OmN1yqdA3qws1znuYq4KVLfMaU%2BMFaNhbA%40mail.gmail.com>
Precedence: bulk

On Wed, Dec 10, 2025 at 4:09=E2=80=AFPM Corey Huinker <corey.huinker@gmail.=
com> wrote:
> I think the change would be worth the destabilization, because it makes i=
t so much easier to talk about complex query plans. Additionally, it would =
make it reasonable to programmatically extract portions of a plan, allowing=
 for much more fine-grained regression tests regarding plans.

I'll wait for more votes before thinking about doing anything about
this, because I have my doubts about whether the consensus will
actually go in favor of such a large change. Or maybe someone else
would like to try mocking it up (even if somewhat imperfectly) so we
can all see just how large an impact it makes.

>> > On the infrastructure patches (0001-0005): these look sensible. The
>> > range table flattening info, elided node tracking, and append node
>
> One thing I am curious about is that by tracking the elided nodes, would =
it make more sense in the long run to have the initial post-naming plan tre=
e be immutable, and generate a separate copy minus the elided parts?

Probably not. Having two entire copies of the plan tree would be
pretty expensive. I think that we've bet on the right idea, namely,
that the primary consumer of plan trees should be the executor, and
the primary goal should be to create plan trees that make the executor
run fast. I believe the right approach is basically what we do today:
you're allowed to put things into the plan that aren't technically
necessary for execution, if they're useful for instrumentation and
observability purposes and they don't add an unreasonable amount of
overhead. These patches basically just extend that existing principle
to a few new things.

--=20
Robert Haas
EDB: http://www.enterprisedb.com