On Fri, Mar 26, 2010 at 6:10 PM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers