Re: Parallel Seq Scan - Mailing list pgsql-hackers

From Kouhei Kaigai
Subject Re: Parallel Seq Scan
Date
Msg-id 9A28C8860F777E439AA12E8AEA7694F801120463@BPXM15GP.gisp.nec.co.jp
Whole thread Raw
In response to Parallel Seq Scan  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Parallel Seq Scan  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
List pgsql-hackers
> On Wed, Jul 29, 2015 at 7:32 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
> >
> > Hi Amit,
> >
> > Could you tell me the code intention around ExecInitFunnel()?
> >
> > ExecInitFunnel() calls InitFunnel() that opens the relation to be
> > scanned by the underlying PartialSeqScan and setup ss_ScanTupleSlot
> > of its scanstate.
> 
> The main need is for relation descriptor which is then required to set
> the scan tuple's slot.  Basically it is required for tuples flowing from
> worker which will use the scan tuple slot of FunnelState.
>
> > According to the comment of InitFunnel(), it open the relation and
> > takes appropriate lock on it. However, an equivalent initialization
> > is also done on InitPartialScanRelation().
> >
> > Why does it acquire the relation lock twice?
> >
> 
> I think locking twice is not required, it is just that I have used the API
> ExecOpenScanRelation() which is used during other node's initialisation
> due to which it lock's twice.  I think in general it should be harmless.
>
Thanks, I could get reason of the implementation.

It looks to me this design is not problematic even if Funnel gets capability
to have multiple sub-plans thus is not associated with a particular relation
as long as target-list and projection-info are appropriately initialized.

Best regards,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>

pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: more RLS oversights
Next
From: Joe Conway
Date:
Subject: Re: CREATE FUNCTION .. LEAKPROOF docs