Re: parallel.c is not marked as test covered

On Wed, May 11, 2016 at 10:38 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Wed, May 11, 2016 at 12:34 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.