Re: remove_useless_joins vs. bug #19560

On Tue, Jul 21, 2026 at 3:52 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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