Re: Rename max_parallel_degree?
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Josh berkus <josh@agliodbs.com>, Tom Lane <tgl@sss.pgh.pa.us>, Amit Kapila <amit.kapila16@gmail.com>, Peter Geoghegan <pg@heroku.com>,
Noah Misch <noah@leadboat.com>, David Rowley <david.rowley@2ndquadrant.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>, Magnus Hagander <magnus@hagander.net>, Bruce Momjian <bruce@momjian.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2016-06-03T12:34:47Z
Lists: pgsql-hackers
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