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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026