Re: plan shape work

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
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-29T14:27:57Z
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.

Robert Haas <robertmhaas@gmail.com> writes:
> I don't really understand why you're so fixed on this point. I think
> that the code as I wrote it is quite a normal way to write code for
> that kind of thing.

Also, we have numerous other places that generate de-duplicated names
in pretty much this way (ruleutils.c's set_rtable_names being a very
closely related case).  I don't think we should go inventing some
random new way to do that.

If it turns out that Robert's code is too slow in practice, I would
prefer to deal with that by using a hashtable to keep track of
already-allocated names, not by changing the user-visible behavior.
I'm content to wait for field complaints before building such logic
though, because I really doubt that queries would ever have so
many subplans as to be a problem.

			regards, tom lane