On Fri, Jun 3, 2016 at 8:30 AM, David G. Johnston <david.g.johns...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
