force_parallel_mode uniqueness

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: force_parallel_mode uniqueness
Date: 2016-05-08 03:42:53
Message-ID: CAKFQuwYwKw1excZho5ULLn7ZyKfZAV=WtDy4mDjOeToLOU2R3Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-05-08 04:10:51 Re: pgsql: Disable BLOB test in pg_dump TAP tests
Previous Message Euler Taveira 2016-05-08 02:08:46 Re: Accurate list of Keywords / Datatypes?