Hello.
At Sat, 23 Feb 2019 22:27:44 +0100, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote in
<81a5c0e9-c17d-28f3-4647-8a4659cdfdb1@2ndquadrant.com>
>
>
> On 2/23/19 8:53 AM, Surafel Temesgen wrote:
> >
> >
> > On Sun, Feb 10, 2019 at 2:22 AM Tomas Vondra
> > <tomas.vondra@2ndquadrant.com <mailto:tomas.vondra@2ndquadrant.com>> wrote:
> >
> >
> >
> > I'm not sure I understand - are you saying every time the user does a
> > FETCH, we have to run the outer plan from scratch? I don't see why would
> > that be necessary? And if it is, how come there's no noticeable
> > performance difference?
> >
> > Can you share a patch implementing the incremental approach, and a query
> > demonstrating the issue?
> >
> >
> > I didn't implement it but its obvious that it doesn't work similarly
> > with previous approach.
> >
>
> Sure, but that's hardly a sufficient argument for the current approach.
>
> > We need different implementation and my plan was to use tuplestore per
> > call and clear
> >
> > it after returning tuple but I see that the plan will not go far because
> > mainly the last returned
> >
> > slot is not the last slot we get from outerPlan execution
> >
>
> I'm sorry, I still don't understand what the supposed problem is. I
> don't think it's all that different from what nodeMaterial.c does, for
> example.
>
> As I explained before, having to execute the outer plan till completion
> before returning any tuples is an issue. So either it needs fixing or an
> explanation why it's not an issue.
One biggest issue seems to be we don't know the total number of
outer tuples before actually reading a null tuple. I doubt of
general shortcut for that. It also seems preventing limit node
from just using materialized outer.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center