On Tue, Jul 21, 2026 at 3:52 AM Tom Lane <[email protected]> wrote: > Anyway, what to do? I imagine we could write some code in > analyzejoins.c to consider whether ECs give rise to base restriction > clauses that they didn't before. But that seems ugly and fragile. > More generally, there is nothing that is not ugly and fragile about > analyzejoins.c's relation removal logic, and the recent addition of > self-join elimination made that situation even worse. I think we > have a permanent maintenance gotcha there.
I feel the same way about this. > I have a modest proposal to make instead: let's nuke all that logic > from orbit. Revise analyzejoins.c so that it does join removals > working strictly on the jointree representation, which is simpler > and far more stable than any of the planner's derived data. Then, > if we successfully removed any joins, throw away all the derived > data and loop back around within query_planner() to redo > deconstruct_jointree and all the rest of it. I prototyped this proposal to see how it would look in code, mainly copying how remove_useless_result_rtes does the removal from the join tree. See attached PoC. Please note that this is far from review-ready, and it only covers outer-join removal, skipping self-join elimination for now, and it lacks badly proper comments and test cases. But it does fix the reported bug. It causes one plan change in the existing tests. I haven't looked into it, but it doesn't seem like a blocker. Overall, the code looks much neater and easier to maintain. I think we should go with this proposal. (I haven't benchmarked planning performance yet, though.) - Richard
v1-0001-wip-refactor-join-removal.patch
Description: Binary data
