force_parallel_mode uniqueness - Mailing list pgsql-hackers

From David G. Johnston
Subject force_parallel_mode uniqueness
Date
Msg-id CAKFQuwYwKw1excZho5ULLn7ZyKfZAV=WtDy4mDjOeToLOU2R3Q@mail.gmail.com
Whole thread Raw
Responses Re: force_parallel_mode uniqueness  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
My take below is that of a user reading our documentation and our projected consistency via that document.

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.

Also, all of the other geoq options get placed here yet max parallel degree is in an entirely different section.  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.

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.

David J.

pgsql-hackers by date:

Previous
From: Euler Taveira
Date:
Subject: Re: Accurate list of Keywords / Datatypes?
Next
From: Stephen Frost
Date:
Subject: Re: [COMMITTERS] pgsql: Disable BLOB test in pg_dump TAP tests