Re: force_parallel_mode uniqueness

On Sun, May 8, 2016 at 2:23 PM, David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> I was thinking more along the lines that it should be called:
>
> parallel_mode (enum)
>
> It would default to "on"
>
> "off" would turn it off (instead of having to set parallel_degree to 0)
>
> And it would have additional enum values for:
>
> "always" - basically what on means in the current setup
> "regress" - the same as the current regress.

So, right now, most people can totally ignore force_parallel_mode.
Under your proposal, parallel query could be disabled either by
setting parallel_mode=off or by setting max_parallel_degree=0 (or 1,
after we do that renumbering). That does not seem like a usability
improvement.

>> We could put max_parallel_degree under "other planner options" rather
>> than "asynchronous behavior". However, I wonder what behavior people
>> will want for parallel operations that are not queries. For example,
>> suppose we have parallel CREATE INDEX. Should the number of workers
>> for that operation also be controlled by max_parallel_degree? If yes,
>> then this shouldn't be a query planner option, because CREATE INDEX is
>> not a query.
>
> Like I said, it isn't clear-cut. But at the moment it is just for queries -
> it could be moved if it gets dual purposed as you describe.

That's true. But it could also be left where it is, and then we
wouldn't have to move it back. I believe that at least some parallel
utility commands are going to arrive in 9.7 - for example, I think
Peter Geoghegan (whom my wife accurately dubbed the Sultan of Sort) is
interested in parallel CREATE INDEX and parallel CLUSTER. Now I don't
know yet whether max_parallel_degree will affect those things or not,
and if it works out that we never use max_parallel_degree for anything
other than queries, then maybe I'll regret putting it where I did.
But I don't think it makes much sense to move it at this point. It
isn't a clear improvement, and we've got plenty of things to tinker
with that are.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company