Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins

> Well, drat.  This idea looked good, and I still think it's good, but
> implementation turns out to be trickier than I thought.  I was thinking
> that RelOptInfos for join rels were essentially independent of which
> pair of sub-relations were used to produce them --- eg, {1 2 3} doesn't
> care if you made it from {1 2} joined to 3 or {1 3} joined to 2, etc.
> That's almost true ... but it falls down on the restrictinfo list,
> because which qual clauses are restrictions at a particular join level
> *does* depend on the path you took to build it.  For example, if you
> have a qual clause "t1.v1 = t2.v2", this clause will be a restrict
> clause for {1 2 3} if you make it from {1 3} joined to 2, but if you
> make it from {1 2} joined to 3 then the clause was already handled when
> {1 2} was produced.

I thought "t1.v1 = t2.v2" would be in t1 RelOptInfo and t2 RelOptInfo. 
Of course, this is a join info restriction, not a restrict info
restriction.


> We could still unify the RelOptInfos for different ways of making the
> same joinrel if we stored restrictinfo lists for joins in individual
> join paths, rather than in the RelOptInfo.  I think that might be worth
> doing, but the change is looking larger and subtler than I thought.
> Probably best not to try to squeeze it in right before beta.

Aren't the restrict-info/join-info of the Final RelOptInfo set only when
the cheapest is found, and before that, the individual Reloptinfo's
restrict-info/join-info that are part of the Path are used?  Maybe these
are stupid questions.

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026