Re: Clean up remove_rel_from_query() after self-join elimination commit
Andrei Lepikhov <lepihov@gmail.com>
From: Andrei Lepikhov <lepihov@gmail.com>
To: Richard Guo <guofenglinux@gmail.com>,
Pg Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-07T08:22:48Z
Lists: pgsql-hackers
On 06/04/2026 10:11, Richard Guo wrote: > Thoughts? Thanks for your efforts! The main goal of the SJE feature was to find common ground within the community - to come up with a solution that everyone could get behind on whether to allow optimisations that address redundant queries and reduce query tree complexity in early planning stages. So, some code roughness was ok. I looked through your code, though maybe not as deeply as this part of the planner deserves. Overall, it looks good, and I didn’t spot any obvious problems, but I do have a few comments. We added some ‘redundant’ checks with future optimisations in mind, so others can rely on these functions to remove tails from query structures or to error if something was left behind. You explicitly write: ‘Each specific caller remains responsible for updating any remaining data structures required by its unique removal logic’ that differs from the initial idea. At the same time, by the end of SJE development, I wasn’t so sure we could invent a universal approach to guarantee the cleanup of the query tree - mostly because of the inherent volatility of the PlannerInfo structure and because we had not agreed to make the parse tree a read-only structure. So, I’m fine with the changes in this patch. -- regards, Andrei Lepikhov, pgEdge
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Clean up remove_rel_from_query() after self-join elimination commit
- 20efbdffeb64 19 (unreleased) landed