Re: plan shape work

On Tue, Sep 9, 2025 at 11:12 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I think what would make a ton more sense is to add
> an enum field to Result that explicitly identifies why it's there.
> We've got at least "apply one-time filter to subplan", "apply per-row
> gating filter to subplan", "represent a relation proven empty", and
> "place-hold for a MinMaxAgg InitPlan".

Thanks, I'll look into this.

> What I have been intending to suggest is that you should add a field
> to join plan nodes that is zero if an inner join, but the relid of
> the outer join RTE if it's an outer join. This is uniquely defined
> because any given join node implements a specific outer join, even
> though the planner's relids for the completed join are (intentionally)
> ambiguous about the order in which multiple joins were done.
>
> The reason I wanted to do this is that I think it'd become possible to
> tighten the assertions in setrefs.c about whether Vars' varnullingrels
> are correct, so that we can always assert that those relid sets are
> exactly thus-and-so and not have to settle for superset/subset tests.
> I've not worked through the details to be entirely sure that this is
> possible, so I didn't bring it up before. But maybe labeling join
> nodes this way would also address Richard's concern. In any case
> it fits into your overall goal of decorating plan trees with more
> information.

Oh, that seems quite elegant! Then we could reasonably expect to
re-find all the relevant RTIs and no others with an appropriate tree
traversal.

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