| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "Jonathan S(dot) Katz" <jonathan(dot)katz(at)excoventures(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Adrien Nayrat <adrien(dot)nayrat(at)anayrat(dot)info>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Explain buffers wrong counter with parallel plans |
| Date: | 2018-08-01 14:27:34 |
| Message-ID: | 28166.1533133654@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> ... But scanning backwards is
> a problem. I'm not exactly sure what the best way of handling that
> is, but one thing I think might work is to save ExecutePlan's
> execute_once flag in the EState and then make the call in nodeLimit.c
> and the one in ExecutePlan itself conditional on that flag. If we
> know that the plan is only going to be executed once, then there can
> never be any backward fetches and it's fine to shut down as soon as we
> finish going forward.
Shouldn't this be dealt with by a eflag bit passed down at executor
init time? What you're describing sounds a lot like somebody
invented a different way because they were unfamiliar with eflags.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2018-08-01 14:35:09 | Re: FailedAssertion on partprune |
| Previous Message | Robert Haas | 2018-08-01 14:21:55 | Re: Explain buffers wrong counter with parallel plans |