On Fri, Jun 3, 2016 at 9:39 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> 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. > > +1. I'm not as convinced as you are that we'll replace the GUC later, > but in any case this is an accurate description of the current > semantics. And I'm really *not* in favor of fudging the name with > the intent of changing the GUC's semantics later --- that would fail > all sorts of compatibility expectations.
Here's a patch change max_parallel_degree to
max_parallel_workers_per_gather, and also changing parallel_degree to
parallel_workers. I haven't tackled adding a separate
max_parallel_workers, at least not yet. Are people OK with this?
Note that there is a dump/restore hazard if people have set the
parallel_degree reloption on a beta1 install, or used ALTER { USER |
DATABASE } .. SET parallel_degree. Can everybody live with that?
Should I bump catversion when applying this?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
parallel-degree-to-workers-v1.patch
Description: binary/octet-stream
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
