Re: Hybrid Hash/Nested Loop joins and caching results from subplans
От | David Rowley |
---|---|
Тема | Re: Hybrid Hash/Nested Loop joins and caching results from subplans |
Дата | |
Msg-id | CAApHDvr+spAK5D3kWXeSvAJnbZRRBratdhdsyQSbA1w5VmQ9LA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Hybrid Hash/Nested Loop joins and caching results from subplans (Andy Fan <zhihui.fan1213@gmail.com>) |
Ответы |
Re: Hybrid Hash/Nested Loop joins and caching results from subplans
Re: Hybrid Hash/Nested Loop joins and caching results from subplans |
Список | pgsql-hackers |
On Fri, 22 May 2020 at 12:12, Andy Fan <zhihui.fan1213@gmail.com> wrote: > Actually I am not sure about what does the "parameterized sub plan" mean (I > treat is a SubPlan Node), so please correct me if I misunderstand you:) Because > the inner plan in nest loop not a SubPlan node actually. so if bind the > facility to SubPlan node, we may loss the chances for nest loop. A parameterized subplan would be a subquery that contains column reference to a query above its own level. The executor changes that column reference into a parameter and the subquery will need to be rescanned each time the parameter's value changes. > And when we > consider the usage for nest loop, we can consider the below example, where this > feature will be more powerful. I didn't quite get the LATERAL support quite done in the version I sent. For now, I'm not considering adding a Result Cache node if there are lateral vars in any location other than the inner side of the nested loop join. I think it'll just be a few lines to make it work though. I wanted to get some feedback before going to too much more trouble to make all cases work. I've now added this patch to the first commitfest of PG14. David
В списке pgsql-hackers по дате отправления: