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.
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? |