Re: plan shape work
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-08-26T14:58:33Z
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
Attachments
- v2-0005-Store-information-about-range-table-flattening-in.patch (application/octet-stream) patch v2-0005
- v2-0003-Assert-that-RTIs-of-joined-rels-are-discoverable-.patch (application/octet-stream) patch v2-0003
- v2-0004-Give-subplans-names-that-are-known-while-planning.patch (application/octet-stream) patch v2-0004
- v2-0001-Keep-track-of-what-RTIs-a-Result-node-is-scanning.patch (application/octet-stream) patch v2-0001
- v2-0002-Consider-a-Result-node-s-relids-in-ExplainPreScan.patch (application/octet-stream) patch v2-0002
- v2-0007-Store-information-about-Append-node-consolidation.patch (application/octet-stream) patch v2-0007
- v2-0006-Store-information-about-elided-nodes-in-the-final.patch (application/octet-stream) patch v2-0006
On Mon, May 19, 2025 at 2:01 PM Robert Haas <robertmhaas@gmail.com> wrote: > A couple of people at pgconf.dev seemed to want to know more about my > ongoing plan shape work, so here are the patches I have currently. Here's an updated patch set. My goal for the September CommitFest is to get patches 0001-0004 committed. Of course, if there are too many objections or too little review, that might not happen, but that's my goal. This patch set is basically unchanged from the previous patch set, except that I've added one new patch. 0007 records information about Append node consolidation into the final plan tree. Without this, when we build an AppendPath or MergeAppendPath and pull up the subpaths from a similar underlying node, we can lose the RTIs from the subordinate node, making it very difficult to analyze the plan after the fact. Just to remark a bit further on the structure of the patch set, 0001-0003 are closely related. The only one I really need committed in order to move forward is 0001, but I think the others are a good idea. There is probably room for some bikeshedding on the output produced by 0002. Then after that, 0004 stands alone as an incredibly important and foundational patch: without it, there's no way to know what the name of a subplan will be until after it's already been planned. I am fairly confident in the approach that I've taken here, but it does cause user-visible changes in EXPLAIN output about which people might conceivably have strong opinions. Getting agreement either on what I've done here or some variant of the approach is essential for me to be able to move forward. Then, 0005-0007 all have to do with preserving in the final plan various details that today would be discarded at the end of planning. While I'm happy to have comments on these now, I'm still not completely confident that I've found all issues in this area or handled them perfectly; hence, I'm not in a hurry to move forward with those just yet. -- Robert Haas EDB: http://www.enterprisedb.com