On Fri, Jun 3, 2016 at 8:30 AM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> How big is the hazard of future-naming this and documenting the present
> limitation? Is the casual user reading explains even going to be aware of
> that particular implementation detail?
Well, see, the nice thing about max_parallel_degree is that it is very
slightly ambiguous, just enough to paper over this. But I'm going to
oppose naming the GUC inaccurately based on a hoped-for future
development project.
Another way to paper over the difference that would be to call this
max_parallel_workers_per_operation. Then we can document that an
operation is a Gather node, and in the future we could document that
it's now a statement. However, if we pick a name like this, then
we're sort of implying that this GUC will control DDL, too.
I think we should just go with max_parallel_workers for a limit on
total parallel workers within max_work_processes, and
max_parallel_workers_per_gather for a per-Gather limit. It's slightly
annoying that we may end up renaming the latter GUC, but not as
annoying as spending another three weeks debating this and missing
beta2.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company