Re: Logic behind parallel default? WAS: Rename max_parallel_degree?

On 05/31/2016 11:10 AM, Tom Lane wrote:
> Josh berkus <josh(at)agliodbs(dot)com> writes:
>> Is there a thread on how we determined this default of 2? I can't find
>> one under likely search terms.
>
> The 9.6 open-items list cites
>
> https://www.postgresql.org/message-id/flat/20160420174631(dot)3qjjhpwsvvx5bau5(at)alap3(dot)anarazel(dot)de

Looks like we didn't decide for the release, just the beta.

I can see two ways to go for the final release:

1. Ship with max_parallel_X = 2 (or similar) and a very low
max_worker_processes (e.g. 4).

2. Ship with max_parallel_X = 1 (or 0, depending), and with a generous
max_worker_processes (e.g. 16).

Argument in favor of (1): we want parallelism to work out of the gate
for users running on low-concurrency systems. These settings would let
some parallelism happen immediately, without overwhelming a 4-to-8-core
system/vm. Tuning for the user would then be fairly easy, as we could
just tell them "set max_worker_processes to half the number of cores you
have".

Argument in favor of (2): parallelism is potentially risky for .0, and
as a result we want it disabled unless users choose to enable it.
Also, defaulting to off lets users make more use of the parallel_degree
table attribute to just enable parallelism on select tables.

Thoughts?

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