Re: plan shape work
От | Robert Haas |
---|---|
Тема | Re: plan shape work |
Дата | |
Msg-id | CA+Tgmob6dUZqFZq2WAhATAOfJT6kFJ_hioeHptH-yo2DPUeCJQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: plan shape work (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: plan shape work
|
Список | pgsql-hackers |
On Tue, Sep 9, 2025 at 11:12 AM Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: