On Mon, May 2, 2016 at 2:44 PM, David G. Johnston <david.g.johnston@gmail.com> wrote: > Does this apply to the extent that a value of 1 is likely worse than 0 since > the leader is now tasked with accumulating but there is only one process > actually working to provide the leader data?
I don't know what that means, but it doesn't work like that. If the worker can't generate data fast enough, the leader will also run the parallel portion of the plan. So 1 is unlikely to be worse than 0; in fact it's often a lot better. > I'm inclined to accept max_parallel_workers where a value of 0 means no > parallelism and the non-zero counts indicate the number of workers in > addition to the required leader.
That's how it works now.
Ok, that's basically what I was trying to figure out. Whether the leader will take on the role of "worker" at lower levels of "parallelism" since if it was dedicated to only aggregating data from other workers it would be a net loss if only one other worker existed.
> Though that does suggest "additional" as a valid option. Something like > "max_additional_workers". Just how overloaded is the term "worker". If > worker is understood to mean "a process which implements execution of [part > of] a query plan" the word additional leaves no ambiguity as to where the > leader is accounted for. > > It does significantly reduce grep-ability though :( > > max_additional_parallel_workers...
I don't think that it's likely to be very clear what "additional" refers to in this context.
I'm not sure how "what" could be interpreted as anything other than "parallel worker"...which I presumed is recognized by the user otherwise "max_parallel_workers" itself exhibits the same problem.
I could see how code usage could be annoying, having to always "+1" the value to get total number of potential workers, but the UI, for me, removes any question of of whether the leader is counted in the set of "parallel workers".