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 →
-
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
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