Re: Clause accidentally pushed down ( Possible bug in Making Vars outer-join aware)
От | Tom Lane |
---|---|
Тема | Re: Clause accidentally pushed down ( Possible bug in Making Vars outer-join aware) |
Дата | |
Msg-id | 2766442.1684265014@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Clause accidentally pushed down ( Possible bug in Making Vars outer-join aware) (Richard Guo <guofenglinux@gmail.com>) |
Ответы |
Re: Clause accidentally pushed down ( Possible bug in Making Vars outer-join aware)
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: