Re: Rename max_parallel_degree? - Mailing list pgsql-hackers
From | Josh berkus |
---|---|
Subject | Re: Rename max_parallel_degree? |
Date | |
Msg-id | 574DBEA4.9000205@agliodbs.com Whole thread Raw |
In response to | Re: Rename max_parallel_degree? (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Responses |
Re: Rename max_parallel_degree?
|
List | pgsql-hackers |
On 05/31/2016 09:15 AM, Robert Haas wrote: > On Sun, May 29, 2016 at 1:33 AM, Noah Misch <noah@leadboat.com> wrote: >> On Fri, May 06, 2016 at 02:52:30PM -0400, Robert Haas wrote: >>> OK, my reading of this thread is that there is a consensus is to >>> redefine max_parallel_degree=1 as "no parallelism" and >>> max_parallel_degree>1 as "parallelism using a leader plus N-1 >>> workers", and along with that, to keep the names unchanged. However, >>> I don't think I can get that done before beta1, at least not without a >>> serious risk of breaking stuff. I can look at this post-beta1. >> >> [This is a generic notification.] >> >> The above-described topic is currently a PostgreSQL 9.6 open item. Robert, >> since you committed the patch believed to have created it, you own this open >> item. If some other commit is more relevant or if this does not belong as a >> 9.6 open item, please let us know. Otherwise, please observe the policy on >> open item ownership[1] and send a status update within 72 hours of this >> message. Include a date for your subsequent status update. Testers may >> discover new open items at any time, and I want to plan to get them all fixed >> well in advance of shipping 9.6rc1. Consequently, I will appreciate your >> efforts toward speedy resolution. Thanks. > > Here is a patch. Note that I still don't agree with this change, but > I'm bowing to the will of the group. > > I think that some of the people who were in favor of this change > should review this patch, including especially the language I wrote > for the documentation. If that happens, and the reviews are positive, > then I will commit this. If that does not happen, then I will > interpret that to mean that there isn't actually all that much > interest in changing this after all and will accordingly recommend > that this open item be removed without further action. > > Here is a test which shows how it works: > > rhaas=# set max_parallel_degree = 100; > SET > rhaas=# alter table pgbench_accounts set (parallel_degree = 10); > ALTER TABLE > rhaas=# explain (analyze) select count(*) from pgbench_accounts; > > QUERY PLAN > -------------------------------------------------------------------------------------------------------------------------------------------------------- > Finalize Aggregate (cost=177436.04..177436.05 rows=1 width=8) > (actual time=383.244..383.244 rows=1 loops=1) > -> Gather (cost=177435.00..177436.01 rows=10 width=8) (actual > time=383.040..383.237 rows=9 loops=1) > Workers Planned: 9 > Workers Launched: 8 I realize there's a lot of water under the bridge here, but I think we're going to get 1000 questions on -general of the type: "I asked for 8 parallel workers, why did I only get 7?". I believe we will regret this change. So, one vote from me to revert. -- -- Josh Berkus Red Hat OSAS (any opinions are my own)
pgsql-hackers by date: