On Fri, Feb 6, 2015 at 11:04 PM, Robert Haas <
robertmhaas@gmail.com> wrote:
>
> On Fri, Feb 6, 2015 at 9:43 AM, Amit Kapila <
amit.kapila16@gmail.com> wrote:
> > Here is the latest patch which fixes reported issues and supported
> > Prepared Statements and Explain Statement for parallel sequential
> > scan.
> >
> > The main purpose is to get the feedback if possible on overall
> > structure/design of code before I goahead.
>
>
> 2. InitiateWorkers() is entirely specific to the concerns of parallel
> sequential scan. After looking this over, I think there are three
> categories of things that need to be clearly separated. Some stuff is
> going to be needed for any parallel query; some stuff is going to be
> needed only for parallel scans but will be needed for any type of
> parallel scan, not just parallel sequential scan[1]; some stuff is
> needed for any type of node that returns tuples but not for nodes that
> don't return tuples (e.g. needed for ParallelSeqScan and
> ParallelHashJoin, but not needed for ParallelHash); and some stuff is
> only going to be needed for parallel sequential scan specifically.
> This patch mixes all of those concerns together in a single function.
> That won't do; this needs to be easily extensible to whatever someone
> wants to parallelize next.
>
Master backend shares Targetlist, Qual, Scanrelid, Rangetable, Bind Params,
Info about Scan range (Blocks), Tuple queues, Instrumentation Info
to worker, going by your suggestion, I think we can separate them as below:
1. parallel query - Target list, Qual, Bind Params, Instrumentation Info
2. parallel scan and nodes that returns tuples - scanrelid, range table, Tuple Queues
3. parallel sequiantial scan specific - Info about Scan range (Blocks)
This is as per current list of things which master backend shares with worker,
if more things are required, then we can decide in which category it falls and
add it accordingly.
Is this similar to what you have in mind?