Re: max_parallel_degree > 0 for 9.6 beta - Mailing list pgsql-hackers

From Gavin Flower
Subject Re: max_parallel_degree > 0 for 9.6 beta
Date
Msg-id 57193186.7090209@archidevsys.co.nz
Whole thread Raw
In response to Re: max_parallel_degree > 0 for 9.6 beta  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: max_parallel_degree > 0 for 9.6 beta
Re: max_parallel_degree > 0 for 9.6 beta
List pgsql-hackers
On 22/04/16 06:07, Robert Haas wrote:
> On Thu, Apr 21, 2016 at 1:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> On Wed, Apr 20, 2016 at 2:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> Andres Freund <andres@anarazel.de> writes:
>>>>> max_parallel_degree currently defaults to 0.  I think we should enable
>>>>> it by default for at least the beta period. Otherwise we're primarily
>>>>> going to get reports back after the release.
>>> So, I suggest that the only sensible non-zero values here are probably
>>> "1" or "2", given a default pool of 8 worker processes system-wide.
>>> Andres told me yesterday he'd vote for "2".  Any other opinions?
>> It has to be at least 2 for beta purposes, else you are not testing
>> situations with more than one worker process at all, which would be
>> rather a large omission no?
> That's what Andres, thought, too.  From my point of view, the big
> thing is to be using workers at all.  It is of course possible that
> there could be some bugs where a single worker is not enough, but
> there's a lot of types of bug where even one worker would probably
> find the problem.  But I'm OK with changing the default to 2.
>
I'm curious.

Why not 4?  As most processors now have at least 4 physical cores, & 
surely it be more likely to flush out race conditions.


Cheers,
Gavin




pgsql-hackers by date:

Previous
From: Christian Ullrich
Date:
Subject: Re: VS 2015 support in src/tools/msvc
Next
From: Alvaro Herrera
Date:
Subject: Re: Should XLogInsert() be done only inside a critical section?