Re: Parallel Seq Scan

On Tue, Jan 20, 2015 at 10:59 PM, Thom Brown <thom(at)linux(dot)com> wrote:
>
> On 20 January 2015 at 14:29, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>>
>> 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.
>
>
> I'm getting an issue:
>
>
>
> # set parallel_seqscan_degree = 10;
> SET
> Time: 0.219 ms
>
> ➤ psql://thom(at)[local]:5488/pgbench
>
>
> ➤ psql://thom(at)[local]:5488/pgbench
>
> # explain analyse select c1 from t1;
>
>
> So setting parallel_seqscan_degree above max_worker_processes causes the
CPU to max out, and the query never returns, or at least not after waiting
2 minutes. Shouldn't it have a ceiling of max_worker_processes?
>

Yes, it should behave that way, but this is not handled in
patch as still we have to decide on what is the best execution
strategy (block-by-block or fixed chunks for different workers)
and based on that I can handle this scenario in patch.

I could return an error for such a scenario or do some work
to handle it seamlessly, but it seems to me that I have to
rework on the same if we select different approach for doing
execution than used in patch, so I am waiting for that to get
decided. I am planing to work on getting the performance data for
both the approaches, so that we can decide which is better
way to go-ahead.

> The original test I performed where I was getting OOM errors now appears
to be fine:
>

Thanks for confirming the same.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com