Re: FETCH FIRST clause PERCENT option
От | Tomas Vondra |
---|---|
Тема | Re: FETCH FIRST clause PERCENT option |
Дата | |
Msg-id | 81a5c0e9-c17d-28f3-4647-8a4659cdfdb1@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: FETCH FIRST clause PERCENT option (Surafel Temesgen <surafel3000@gmail.com>) |
Ответы |
Re: FETCH FIRST clause PERCENT option
Re: FETCH FIRST clause PERCENT option |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: