Re: [HACKERS] Parallel Index Scans - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Parallel Index Scans
Date
Msg-id CA+TgmoZqyK8a3LfMuRBX+nKQ2u6OOUYkAuJupNnarYYcuANenw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Parallel Index Scans  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [HACKERS] Parallel Index Scans  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Thu, Jan 19, 2017 at 4:26 AM, Amit Kapila <amit.kapila16@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
haveenough 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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Declarative partitioning - another take
Next
From: Dmitry Fedin
Date:
Subject: [HACKERS] [PATCH] Change missleading comment for tm_mon field of pg_tm structure