Re: plan shape work
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Richard Guo <guofenglinux@gmail.com>,
Alexandra Wang <alexandra.wang.oss@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
"bruce@momjian.us" <bruce@momjian.us>, lepihov@gmail.com
Date: 2025-09-09T16:00:26Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Assign each subquery a unique name prior to planning it.
- 8c49a484e8eb 19 (unreleased) landed
-
Keep track of what RTIs a Result node is scanning.
- f2bae51dfd5b 19 (unreleased) landed
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