Re: Logic behind parallel default? WAS: Rename max_parallel_degree?
Joshua D. Drake <jd@commandprompt.com>
From: "Joshua D. Drake" <jd@commandprompt.com>
To: Josh berkus <josh@agliodbs.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Geoghegan <pg@heroku.com>, Robert Haas <robertmhaas@gmail.com>,
Noah Misch <noah@leadboat.com>, David Rowley <david.rowley@2ndquadrant.com>,
Amit Kapila <amit.kapila16@gmail.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
Magnus Hagander <magnus@hagander.net>, Bruce Momjian <bruce@momjian.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2016-05-31T18:12:23Z
Lists: pgsql-hackers
On 05/31/2016 11:05 AM, Josh berkus wrote:
> 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.
>
I don't remember the thread but I seem to recall that the default of 2
is explicitly during Beta, RC etc... so that we can see what happens.
Robert could speak better to that.
JD
--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.