Re: join removal

On Fri, Mar 26, 2010 at 6:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Reading through the "optimizer functions" section of
>> src/backend/optimizer/README, it seems like the earliest point at
>> which we could do this would be just before the call to
>> make_one_rel().  I think that would eliminate some redundant
>> computation.
>
> Maybe.  It would also add a new pass over the join tree that, in
> 99% of cases, would make no useful contribution whatever.  It's
> possible that this would still be cheaper than a lot of failed calls
> to join_is_removable, but I'm unconvinced --- we were able to make
> the failure path through that pretty durn cheap for most simple cases.
> The approach you're sketching still involves a combinatorial search
> so I doubt it's going to be cheap.

I'm not totally sure about this but I think it's possible to do this
without a combinatorial search. Suppose we just iterate over the list
of
SpecialJoinInfo structures and look for those where jointype is LEFT,
delay_upper_joins is false, and min_righthand is a singleton; and then
consider the removability of a join between min_lefthand and
min_righthand. I might be missing a case, but I think whatever answer
we get from that calculation is the answer, period. Adding more
relations to the LHS won't change anything.

> Yeah.  I had been thinking that we could build the RelOptInfo and
> IndexOptInfo structs earlier, but really all of the
> clause-classification work done by deconstruct_jointree is important
> as well for this function's purposes, so it's not that easy to push
> back to prepjointree :-(.  I suspect that any such attempt would end
> up requiring a massive rethinking of the order of operations in the
> planner.  Maybe we should do that sometime but I'm not eager for it.

Agree. If we ever do that, one of the things to think about is
minimizing memory consumption...

...Robert