Hello. At Sat, 23 Feb 2019 22:27:44 +0100, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote in <81a5c0e9-c17d-28f3-4647-8a4659cdf...@2ndquadrant.com> > > > On 2/23/19 8:53 AM, Surafel Temesgen wrote: > > > > > > On Sun, Feb 10, 2019 at 2:22 AM Tomas Vondra > > <tomas.von...@2ndquadrant.com <mailto:tomas.von...@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
