Richard Guo <guofenglinux@gmail.com> writes:
> I doubt this is always right to add joins_below to all the vars
> belonging to sjinfo->syn_lefthand. What if the joins in joins_below
> cannot commute with each other? As a counterexample, consider the query
> below which causes assertion failure in search_indexed_tlist_for_var.
> The query is designed so that t1/t2 join cannot commute with t2/t3 join
> but can commute with t3/t4 join.
> explain (costs off)
> select * from t t1
> left join t t2 on true
> left join t t3 on true
> left join t t4 on t2.a = t3.a;
Hm. Actually, t1/t2 *can't* commute with the t4 join. You can re-order
the t2 and t3 joins per identity 2:
select * from t t1
left join t t3 on true
left join t t2 on true
left join t t4 on t2.a = t3.a;
but you're still stuck, identity 3 applies nowhere (because in either
case, the putative Pbc clause has also got a reference to A).
make_outerjoininfo is setting the t4 join's commute_below_l to include
t1/t2, but it seems to me that that indicates inadequate analysis in
make_outerjoininfo. Is there still a problem here if we get rid of
that overoptimistic conclusion? We should strive to do so even if
it's not fixing an observable problem, because in any case it's
causing the planner to waste time on unreachable join orders.
regards, tom lane
