Re: BUG #18627: Regression (15 -> 16) - Join removal not performed when join condition spans multiple tables

Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> On Mon, Sep 23, 2024 at 12:56 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> That's ugly for sure, and it would only revert to the status
>> quo ante. But I'm not seeing a better way right now.

> It seems to me that this approach basically reverts the changes in
> 8538519db. I'm afraid this would re-introduce the bug fixed by that
> commit.

Ugh, you're probably right.

I'm taking a second look at the idea of regenerating the attr_needed
values altogether. It doesn't look that bad, especially if we cheat
to the extent of preserving the existing "relation 0" bits (that is,
tlist and HAVING references). That's fine since we could never
remove a rel that supplies Vars used in those places. Then we
basically have to reconstruct surviving references from

* EquivalenceClasses
* joinclauses (available from the rels' joinlists)
* lateral references (available from the rels' lateral_vars lists)
* surviving placeholders (much like fix_placeholder_input_needed_levels)

The need to again call pull_var_clause on these clauses is mildly
annoying but I think it won't be that bad runtime-wise. Slightly
more annoying is that a joinclause mentioning N relations would be
visited N times. Perhaps we could de-duplicate using rinfo
serial numbers?

While I've not written any code yet, it seems like this route
would lead to a bigger patch than we'd want to back-patch into
v16 or v17. So that's not great; but on the other hand it took
a year for anyone to notice this regression, so maybe we can get
away with not fixing it in those branches.

regards, tom lane