| From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
|---|---|
| To: | Surafel Temesgen <surafel3000(at)gmail(dot)com> |
| Cc: | vik(dot)fearing(at)2ndquadrant(dot)com, Mark Dilger <hornschnorter(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, andrew(at)tao11(dot)riddles(dot)org(dot)uk |
| Subject: | Re: FETCH FIRST clause PERCENT option |
| Date: | 2019-02-09 23:22:41 |
| Message-ID: | 4a1f303c-26ba-2de9-b6ed-d16ef1c21b36@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 1/30/19 7:07 AM, Surafel Temesgen wrote:
>
>
> On Mon, Jan 28, 2019 at 1:28 AM Tomas Vondra
> <tomas(dot)vondra(at)2ndquadrant(dot)com <mailto:tomas(dot)vondra(at)2ndquadrant(dot)com>> wrote:
>
>
>
> OK. Does that mean you agree the incremental approach is reasonable?
>
>
> there are no noticeable performance difference but i love previous
> approach more regarding cursor operation it fetch tuple forward and
> backward from tuplestore only but in incremental approach we have to
> re execute outer node in every forward and backward fetching operation
>
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?
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Julien Rouhaud | 2019-02-09 23:24:24 | Re: executor relation handling |
| Previous Message | Thomas Munro | 2019-02-09 21:06:30 | Re: dsa_allocate() faliure |