Re: BUG #18953: Planner fails to build plan for complex query with LATERAL references
От | Tom Lane |
---|---|
Тема | Re: BUG #18953: Planner fails to build plan for complex query with LATERAL references |
Дата | |
Msg-id | 527134.1750087495@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18953: Planner fails to build plan for complex query with LATERAL references (Richard Guo <guofenglinux@gmail.com>) |
Список | pgsql-bugs |
Richard Guo <guofenglinux@gmail.com> writes: > In identify_current_nestloop_params(), I wonder if we should use the > join path's required-outer rels rather than the left path's as the > "outerrelids". It seems that there may be cases where the join path > is parameterized by some other rel while its left path itself is not > parameterized at all. I went back and forth on that. In principle, we shouldn't put such a calculation into the left path if it's not parameterized by the rel supplying the required value. In practice, if the required value is getting passed down to the join path then it's available to the left path too, so it should work fine whether the left path is marked like that or not. In the only test case I have that exercises this logic, both paths are marked with the required_outer anyway, so it doesn't seem to matter. If we can find a case where that's not so, then probably we should do it the other way. > Regarding the test case, I wonder if we should add another test query > to specifically test the changes in create_nestloop_plan(). We already have one; there's a query in join.sql (originally added to test the have_dangerous_phv logic) that fails without the additions to push a PHV into the left path. Admittedly, that's behind the scenes so maybe we ought to add an EXPLAIN to make it more apparent. regards, tom lane
В списке pgsql-bugs по дате отправления: