Re: Parallel Seq Scan

On Thu, Jan 15, 2015 at 6:57 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Mon, Jan 12, 2015 at 3:25 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> >
> > Yeah, you need two separate global variables pointing to shm_mq
> > objects, one of which gets used by pqmq.c for errors and the other of
> > which gets used by printtup.c for tuples.
> >
>
> Okay, I will try to change the way as suggested without doing
> switching, but this way we need to do it separately for 'T', 'D', and
> 'C' messages.
>

I have taken care of integrating the parallel sequence scan with the

latest patch posted (parallel-mode-v1.patch) by Robert at below

location:

http://www.postgresql.org/message-id/CA+TgmoZdUK4K3XHBxc9vM-82khourEZdvQWTfgLhWsd2R2aAGQ@mail.gmail.com

Changes in this version

-----------------------------------------------

1. As mentioned previously, I have exposed one parameter

ParallelWorkerNumber as used in parallel-mode patch.

2. Enabled tuple queue to be used for passing tuples from

worker backend to master backend along with error queue

as per suggestion by Robert in the mail above.

3. Involved master backend to scan the heap directly when

tuples are not available in any shared memory tuple queue.

4. Introduced 3 new parameters (cpu_tuple_comm_cost,

parallel_setup_cost, parallel_startup_cost) for deciding the cost

of parallel plan.  Currently, I have kept the default values for

parallel_setup_cost and parallel_startup_cost as 0.0, as those

require some experiments.

5. Fixed some issues (related to memory increase as reported

upthread by Thom Brown and general feature issues found during

test)

Note - I have yet to handle the new node types introduced at some

of the places and need to verify prepared queries and some other

things, however I think it will be good if I can get some feedback

at current stage.