Re: plan shape work
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-08-26T20:16:34Z
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, Aug 26, 2025 at 10:58:33AM -0400, Robert Haas wrote: > During planning, there is one range table per subquery; at the end if > planning, those separate range tables are flattened into a single > range table. Prior to this change, it was impractical for code > examining the final plan to understand which parts of the flattened > range table came from which subquery's range table. > > If the only consumer of the final plan is the executor, that is > completely fine. However, if some code wants to examine the final > plan, or what happens when we execute it, and extract information from > it that be used in future planning cycles, it's inconvenient. I am very interested in how plans can be used for future planning. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.