Re: Parallel Seq Scan
От | Kouhei Kaigai |
---|---|
Тема | Re: Parallel Seq Scan |
Дата | |
Msg-id | 9A28C8860F777E439AA12E8AEA7694F801120463@BPXM15GP.gisp.nec.co.jp обсуждение исходный текст |
Ответ на | Parallel Seq Scan (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Parallel Seq Scan
|
Список | 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 по дате отправления: