Re: Parallel Seq Scan - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Parallel Seq Scan
Date
Msg-id CA+TgmoZcFb_Q=pmBdMYHtrncwuSHHuORoUNcvft6hv4sLnxE1A@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Seq Scan  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Wed, Oct 14, 2015 at 12:30 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> - I continue to think GetParallelShmToc is the wrong approach.
>> Instead, each time ExecParallelInitializeDSM or
>> ExecParallelInitializeDSM calls a nodetype-specific initialized
>> function (as described in the previous point), have it pass d->pcxt as
>> an argument.  The node can get the toc from there if it needs it.  I
>> suppose it could store a pointer to the toc in its scanstate if it
>> needs it, but it really shouldn't.  Instead, it should store a pointer
>> to, say, the ParallelHeapScanDesc in the scanstate.
>
> How will this idea work for worker backend.  Basically in worker
> if want something like this to work, toc has to be passed via
> QueryDesc to Estate and then we can retrieve ParallelHeapScanDesc
> during PartialSeqScan initialization (ExecInitPartialSeqScan).
> Do you have something else in mind?

Good question.  I think when the worker starts up it should call yet
another planstate-walker, e.g. ExecParallelInitializeWorker, which can
call nodetype-specific functions for parallel-aware nodes and give
each of them a chance to access the toc and store a pointer to their
parallel shared state (ParallelHeapScanDesc in this case) in their
scanstate.  I think this should get called from ParallelQueryMain
after ExecutorStart and before ExecutorRun:
ExecParallelInitializeWorker(queryDesc->planstate, toc).

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: More work on SortSupport for text - strcoll() and strxfrm() caching
Next
From: Tom Lane
Date:
Subject: A bunch of regular-expression improvements