On Mon, Jan 11, 2016 at 3:14 AM, Peter Geoghegan <pg@heroku.com> wrote: > > On Sun, Jan 10, 2016 at 9:13 AM, Robert Haas <robertmhaas@gmail.com> wrote: > > Now, you might wonder why it is that the leader cannot also sort runs, > just as a worker would. It's possible, but it isn't exactly > straightforward. You have to have special cases in several places, > even though it probably is going to be uncommon to only have one > BackgroundWorkerSlot available in practice. It's simpler to just > opt-out, and seems better given that max_parallel_degree is a way of > resource limiting based on available cores (it's certainly not about > the availability of shared memory for the BackgroundWorkerSlot array). > > More importantly, I have other, entirely general concerns. Other major > RDBMSs have settings that are very similar to max_parallel_degree, > with a setting of 1 effectively disabling all parallelism. Both Oracle > and SQL Server have settings that they both call the "maximum degree > or parallelism". I think it's a bit odd that with Postgres, > max_parallel_degree = 1 can still use parallelism at all. I have to > wonder: are we conflating controlling the resources used by parallel > operations with how shared memory is doled out? >
Your point is genuine, but OTOH let us say if max_parallel_degree = 1 means parallelism is disabled then when somebody sets max_parallel_degree = 2, then it looks somewhat odd to me that, it will mean that 1 worker process can be used for parallel query. Also, I think the parallel query will be able to get parallel workers till max_worker_processes + 1 which seems less intuitive than the current.
On your point of other databases, I have also checked and it seems like some of other databases like sybase [1] also provide a similar parameter
and value 1 means serial execution, so we might also want to consider it similarly, but to me the current setting sounds quite intuitive, however if more people also feel the same as you, then we should change it.