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

Поиск
Список
Период
Сортировка
От Josh berkus
Тема Re: Logic behind parallel default? WAS: Rename max_parallel_degree?
Дата
Msg-id 574DDBE2.6020609@agliodbs.com
обсуждение исходный текст
Ответ на Re: Rename max_parallel_degree?  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: Logic behind parallel default? WAS: Rename max_parallel_degree?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 05/31/2016 11:10 AM, Tom Lane wrote:
> Josh berkus <josh@agliodbs.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.3qjjhpwsvvx5bau5@alap3.anarazel.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)



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Josh berkus
Дата:
Сообщение: Re: Rename max_parallel_degree?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Rename max_parallel_degree?