On Tue, May 3, 2016 at 11:42 PM, David Rowley <david.row...@2ndquadrant.com> wrote: >>> Magnus seems OK with the way things are. >>> Peter wants to change either the fact that it is 0-based or the fact >>> that it is called degree, but is OK with either. >>> Tom doesn't like "degree" and also thinks anything called degree >>> should 1-based, but it sounds like he's more interested in changing >>> the first thing than the second one >>> Bruce and JD seemed to like degree -> workers. >>> JD also suggested another option that nobody else endorsed. >>> Alvaro suggested another option that nobody else endorsed. >>> >>> Does anyone else want to vote? >> >> I think the way it is currently in HEAD seems easy to correlate how the >> feature works, but may be it appears to me that way because I am involved >> from long time with this implementation. I also think one can easily >> confused among max_parallel_workers and max_worker_processes, so if we want >> to change, my vote goes with changing the default of max_parallel_degree to >> 1 (as suggested by Peter G.). > > I'd like to put my +1 against making the current GUCs with their > current names 1-based, rather than 0-based. Doing anything else like > giving them new names seems like reinventing the wheel. > > My reasoning is that the only gripe that I understand against the > current names is that the "degree" term appears not to be aligned with > what other databases do. > > I think that actual rows / (degree+1) might get confusing for people, > such as in the following EXPLAIN ANALYZE output. > > Workers Launched: 2 > -> Partial Aggregate (cost=96331.21..96331.22 rows=1 > width=8) (actual time=584.297..584.297 rows=1 loops=3) > -> Parallel Seq Scan on a (cost=0.00..85914.57 > rows=4166657 width=0) (actual time=1.566..347.091 rows=3333333 > loops=3) > > The above would make more sense with max_parallel_degree=3. > > I also think that the parallel query, at its best will have the > workers working hard for their tuples. In such cases the main process > will be helping out much more, and the more it helps the more a > 1-based degree makes sense. Also I can't stretch my imagination enough > to imagine how any other database can handle worker tuples any > differently than us... Surely their main process/thread must marshal > worker's tuples the same as what we do? And if they use a 1-based > degree for that, then surely we can too.
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. -- 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
