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

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

Indeed.  I think it's premature to have this discussion.  The plan
was to evaluate near the end of beta, when we (hopefully) have a
better feeling for how buggy parallel query is likely to be.

> Also, defaulting to off lets users make more use of the parallel_degree
> table attribute to just enable parallelism on select tables.

Well, that's an interesting point.  The current coding is that
parallel_degree is an upper limit on per-table workers, and
max_parallel_degree also limits it.  So if you want parallel scans only on
a small set of tables, parallel_degree is not an especially convenient way
to get to that.  Whether we measure it in workers or cores doesn't change
this conclusion.

It might be worth reconsidering what per-table knobs we should provide
exactly, but that's orthogonal to the main point under discussion.
        regards, tom lane



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

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: Rename synchronous_standby_names?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system