Re: Parallel Seq Scan - Mailing list pgsql-hackers
From | Kouhei Kaigai |
---|---|
Subject | Re: Parallel Seq Scan |
Date | |
Msg-id | 9A28C8860F777E439AA12E8AEA7694F801121973@BPXM15GP.gisp.nec.co.jp Whole thread Raw |
In response to | Re: Parallel Seq Scan (Kouhei Kaigai <kaigai@ak.jp.nec.com>) |
Responses |
Re: Parallel Seq Scan
(Amit Kapila <amit.kapila16@gmail.com>)
|
List | pgsql-hackers |
Amit, Let me ask three more detailed questions. Why Funnel has a valid qual of the subplan? The 2nd argument of make_funnel() is qualifier of the subplan (PartialSeqScan) then it is initialized at ExecInitFunnel, but never executed on the run-time. Why does Funnel node has useless qualifier expression here (even though it is harmless)? Why Funnel delivered from Scan? Even though it constructs a compatible target-list with underlying partial-scan node, it does not require the node is also delivered from Scan. For example, Sort or Append don't change the target-list definition from its input, also don't have its own qualifier. It seems to me the definition below is more suitable... typedef struct Funnel { Plan plan; int num_workers; } Funnel; Does ExecFunnel() need to have a special code path to handle EvalPlanQual()? Probably, it just calls underlying node in the local context. ExecScan() of PartialSeqScan will check its qualifier towards estate->es_epqTuple[]. Thanks, -- NEC Business Creation Division / PG-Strom Project KaiGai Kohei <kaigai@ak.jp.nec.com> > -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Kouhei Kaigai > Sent: Thursday, July 30, 2015 8:45 AM > To: Amit Kapila > Cc: Robert Haas; Gavin Flower; Jeff Davis; Andres Freund; Amit Langote; Amit > Langote; Fabrízio Mello; Thom Brown; Stephen Frost; pgsql-hackers; Haribabu Kommi > Subject: Re: [HACKERS] Parallel Seq Scan > > > 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> > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers
pgsql-hackers by date: