Re: force_parallel_mode uniqueness

On Sat, May 7, 2016 at 11:42 PM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> All of the other planner GUCs are basically, {on, off, special} with on or
> special the default as appropriate for the feature - since most/all features
> default to enabled.  While I get that the expected usage is to set this to
> off (which really leaves parallel mode in its default on behavior) and then
> reduce the parallel workers to zero to disable that runs contrary to all of
> the other switches listed alongside force_parallel_mode.
> constraint_exclusion seems like something to be emulated here.

I am not really sure what you are suggesting here.  If you're saying
that you don't like the ordering regress > on > off, because there are
other GUCs where the intermediate values are all between "on" and
"off", then I think that's silly.  We should name and order the
options based on what makes sense, not based on what made sense for
other options.  Note that if you think there are no other GUCs which
have a value greater than "on", see also
synchronous_commit=remote_apply.

> Also, all of the other geoq options get placed here yet max parallel degree
> is in an entirely different section.

max_parallel_degree has nothing to do with GEQO, so I don't know that
the location of "other" GEQO options has much to do with anything.  It
also has nothing to do with force_parallel_mode, which is what this
email was about until you abruptly switched topics.

> I'm a bit torn on this point though
> since it does fit nicely in asynchronous behavior.  I think the next thought
> finds the happy middle.

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.

> If nothing else this option should include a link to max_parallel_degree and
> vice-versa.  Noting how to disable the feature in this section, if the guc
> semantics are not changed, would be good too.  That note would likely
> suffice to establish the linking term to parallel degree.  Something can be
> devised, even if just a see also, to link back.

It's probably worth mentioning under force_parallel_mode that it will
have no effect if parallel query is disabled by the
max_parallel_degree setting.  But it is completely unnecessary IMHO
for max_parallel_degree to link to force_parallel_mode.  Most people
should not be using force_parallel_mode; it is there for testing
whether functions are correctly labeled as to parallel safety and
that's it.

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