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

>> This looks like it should be a fairly straightforward change: we should
>> meld make_join_rel and get_join_rel so that a requested join rel is
>> first searched for in root->join_rel_list, and only built if not present
>> (like get_base_rel).  The join rel would have a flat relids list from the
>> beginning, since it would be agnostic about which inner and outer subset
>> rels should be used to produce it.

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.

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.

I will set aside the code I already rewrote for this purpose, and come
back to it after we start 7.1.
        regards, tom lane