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.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
