On Thu, Jan 19, 2017 at 4:26 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> Fixed.
I think that the whole idea of GatherSupportsBackwardScan is wrong.
Gather doesn't support a backwards scan under any circumstances,
whether the underlying node does or not. You can read the tuples
once, in order, and you can't back up. That's what supporting a
backward scan means: you can back up and then move forward again.
It's there to support cursor operations.
Also note this comment in ExecSupportsBackwardsScan, which seems just
as relevant to parallel index scans as anything else:
/*
* Parallel-aware nodes return a subset of the tuples in each worker, and
* in general we can't expect to have enough bookkeeping state to know
* which ones we returned in this worker as opposed to some other worker.
*/
if (node->parallel_aware)
return false;
If all of that were no issue, the considerations in
TargetListSupportsBackwardScan could be a problem, too. But I think
there shouldn't be any issue having Gather just continue to return
false.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
