public inbox for [email protected]
help / color / mirror / Atom feedFrom: Robert Haas <[email protected]>
To: Corey Huinker <[email protected]>
Cc: Amit Langote <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: pg_plan_advice
Date: Wed, 10 Dec 2025 16:29:50 -0500
Message-ID: <CA+TgmoZdvRJY62T_OmN1yqdA3qws1znuYq4KVLfMaU+MFaNhbA@mail.gmail.com> (raw)
In-Reply-To: <CADkLM=d0yH-+z4T6SmuAjYvCj5n7PUVTUJVue48Y60yZFwRVhA@mail.gmail.com>
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>
On Wed, Dec 10, 2025 at 4:09 PM Corey Huinker <[email protected]> wrote:
> I think the change would be worth the destabilization, because it makes it 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 tree 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.
--
Robert Haas
EDB: http://www.enterprisedb.com
view thread (133+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: pg_plan_advice
In-Reply-To: <CA+TgmoZdvRJY62T_OmN1yqdA3qws1znuYq4KVLfMaU+MFaNhbA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox