Re: Logic behind parallel default? WAS: Rename max_parallel_degree? - Mailing list pgsql-hackers

From Josh berkus
Subject Re: Logic behind parallel default? WAS: Rename max_parallel_degree?
Date
Msg-id 574DD27F.4060409@agliodbs.com
Whole thread Raw
In response to Re: Rename max_parallel_degree?  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Logic behind parallel default? WAS: Rename max_parallel_degree?
Re: Logic behind parallel default? WAS: Rename max_parallel_degree?
List pgsql-hackers
On 05/31/2016 11:00 AM, Tom Lane wrote:
> !          If this occurs, the plan will run with fewer workers than expected,
> !          which may be inefficient.  The default value is 2.  Setting this
> !          value to 0 disables parallel query execution.

Is there a thread on how we determined this default of 2?  I can't find
one under likely search terms.

I'm concerned about the effect of overallocating parallel workers on
systems which are already running out of cores (e.g. AWS instances), and
run with default settings.  Possibly max_parallel_workers takes care of
this, which is why I want to understand the logic here.

-- 
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Rename synchronous_standby_names?
Next
From: "David G. Johnston"
Date:
Subject: Re: Rename max_parallel_degree?