Re: Parallel Seq Scan

On Thu, Oct 15, 2015 at 11:45 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Thu, Oct 15, 2015 at 5:39 PM, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
> wrote:
>>
>>
>>
>> On Thu, Oct 15, 2015 at 6:32 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
>> wrote:
>> > On Wed, Oct 14, 2015 at 3:29 AM, Robert Haas <robertmhaas(at)gmail(dot)com>
>> > wrote:
>> > I think this got messed up while rebasing on top of Gather node
>> > changes, but nonetheless, I have changed it such that PartialSeqScan
>> > node handling is after SeqScan.
>>
>> Currently, the explain analyze of parallel seq scan plan is not showing
>> the allocated number of workers
>> including the planned workers.I feel this information is good for users in
>> understanding the performance
>> difference that is coming with parallel seq scan. It may be missed in
>> recent patch series. It was discussed
>> in[1].
>>
>
> I am aware of that and purposefully kept it for a consecutive patch.
> There are other things as well which I have left out from this patch
> and those are:
> a. Early stop of executor for Rescan purpose
> b. Support of pushdown for plans containing InitPlan and SubPlans
>
> Then there is more related work like
> a. Support for prepared statements
>

OK.

During the test with latest patch, I found a dead lock between worker
and backend
on relation lock. To minimize the test scenario, I changed the number
of pages required
to start one worker to 1 and all parallel cost parameters as zero.

Backend is waiting for the tuples from workers, workers are waiting on
lock of relation.
Attached is the sql script that can reproduce this issue.

Regards,
Hari Babu
Fujitsu Australia