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
|
| Список | pgsql-hackers |
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 по дате отправления: