From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Hybrid Hash/Nested Loop joins and caching results from subplans |
Date: | 2020-05-25 07:53:27 |
Message-ID: | CAApHDvr+spAK5D3kWXeSvAJnbZRRBratdhdsyQSbA1w5VmQ9LA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 22 May 2020 at 12:12, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2020-05-25 08:54:03 | Re: PG 13 release notes, first draft |
Previous Message | Dmitry Dolgov | 2020-05-25 07:16:26 | Re: [PATCH] Keeps tracking the uniqueness with UniqueKey |