Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b7oZC-0001fV-He for pgsql-hackers@arkaria.postgresql.org; Tue, 31 May 2016 18:39:02 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1b7oZB-0007EI-ND for pgsql-hackers@arkaria.postgresql.org; Tue, 31 May 2016 18:39:01 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1b7oXp-0005HP-6Q for pgsql-hackers@postgresql.org; Tue, 31 May 2016 18:37:37 +0000 Received: from zmcc-5-mx.zmailcloud.com ([192.198.93.228]) by makus.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b7oXm-0005M0-Kj for pgsql-hackers@postgresql.org; Tue, 31 May 2016 18:37:35 +0000 Received: from zmcc-5-mta-1.zmailcloud.com (127.37.197.104.bc.googleusercontent.com [104.197.37.127]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by zmcc-5-mx.zmailcloud.com (Postfix) with ESMTPS id A84E15204F5; Tue, 31 May 2016 14:37:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 51C8CC1DA8; Tue, 31 May 2016 18:37:33 +0000 (UTC) Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id zSas3os71fQP; Tue, 31 May 2016 18:37:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 24B70C2018; Tue, 31 May 2016 18:37:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmcc-5-mta-1.zmailcloud.com Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6t7Nf_R9R9xc; Tue, 31 May 2016 18:37:31 +0000 (UTC) Received: from redhat.com (c-98-246-109-153.hsd1.or.comcast.net [98.246.109.153]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTPSA id 2AC98C1D80; Tue, 31 May 2016 18:37:31 +0000 (UTC) Subject: Re: Rename max_parallel_degree? To: Peter Geoghegan References: <20160426152217.GA548975@alvherre.pgsql> <574DC881.5010006@agliodbs.com> <574DCDFC.6060506@agliodbs.com> <574DD1CE.2000307@agliodbs.com> <574DD64A.9090600@agliodbs.com> Cc: Peter Eisentraut , Tom Lane , Robert Haas , Noah Misch , David Rowley , Amit Kapila , Alvaro Herrera , Magnus Hagander , Bruce Momjian , PostgreSQL-development From: Josh berkus Message-ID: <574DD9EA.4050709@agliodbs.com> Date: Tue, 31 May 2016 11:37:30 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 05/31/2016 11:27 AM, Peter Geoghegan wrote: > On Tue, May 31, 2016 at 11:22 AM, Josh berkus wrote: >>> I think we can hope that developers are going to be less confused about >>> that than users. >> >> Makes sense. >=20 > Maybe EXPLAIN doesn't have to use the term parallel worker at all. It > can instead use a slightly broader terminology, possibly including the > term "core". >=20 >> One more consistency question: what's the effect of running out of >> max_parallel_workers? >> >> That is, say max_parallel_workers is set to 10, and 8 are already >> allocated. If I ask for max_parallel_X =3D 4, how many cores to I use? >=20 > Well, it depends on the planner, of course. But when constrained only > by the availability of worker processes, then your example could use 3 > cores -- the 2 remaining parallel workers, plus the leader itself. >=20 >> Presumably the leader isn't counted towards max_parallel_workers? ^^^^ (oops, I meant max_worker_processes above) So, there's six things we'd like to make consistent to limit user confusion: 1. max_parallel_X and number of cores used 2. max_parallel_X and EXPLAIN output 3. max_parallel_X and gatekeeping via max_worker_processes 4. max_parallel_X and parallelism of operations (i.e. 2 =3D=3D 2 parallel scanners) 5. settings in other similar databases (does someone have specific citations for this)? 6. consistency with other GUCs (0 or -1 to disable settings) We can't actually make all five things consistent, as some of them are contradictory; for example, (1) and (3) cannot be reconciled. So we need to evaluate which things are more likely to cause confusion. My general evaluation would be to make the GUC be the number of additional workers used, not the total number (including the leader). =46rom my perspective, that makes (2), (3) and (6) consistent, and (4) cannot be made consistent because different types of parallel nodes behave different ways (i.e, some are parallel with only 1 additional worker and some are not). However, I'm resigned to the fact that user confusion is inevitable whichever way we choose, and could be persuaded the other way. --=20 -- Josh Berkus Red Hat OSAS (any opinions are my own) --=20 Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers