Re: parallel.c is not marked as test covered

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: parallel.c is not marked as test covered
Дата
Msg-id CAKFQuwZAjVxzhMow_oE5jaEs_zrGnEAqr7euJWan9JJcP3H8Qw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: parallel.c is not marked as test covered  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: parallel.c is not marked as test covered  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Wed, May 11, 2016 at 10:38 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Wed, May 11, 2016 at 12:34 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hmm, that is strange.  I would have expected that to stuff a Gather on
>> top of the Aggregate.  I wonder why it's not doing that.
>
> The reason is that create_plain_partial_paths() contains a hard-wired
> decision not to generate any partial paths for relations smaller than
> 1000 blocks, which means that no partial path will ever be generated
> for *any* relation in the standard regression tests, force_parallel_mode
> or no.

Well that's an interesting theory, except that you've completely
missed the point of force_parallel_mode.  force_parallel_mode pushes a
special Gather node on top of any plan that is not already parallel in
some way but which is parallel-safe.   That special Gather node runs
only in the worker, not the leader, and always uses just one worker.

​What happens when there are no workers available due to max_worker_processes ​already being assigned?

Related question, if max_parallel_degree is >1 and "the requested number of workers may not actually be available at runtime" is true, does the degree of parallelism minimize at 1 worker + leader or will the leader simply run the query by itself?

David J.

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

Предыдущее
От: Christopher Browne
Дата:
Сообщение: Re: Academic help for Postgres
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Re: Need help debugging why autovacuum seems "stuck" -- until I use superuser to vacuum freeze pg_database