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 →
  1. Assign each subquery a unique name prior to planning it.

  2. Keep track of what RTIs a Result node is scanning.

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.