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
