Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kJzeh-0006Tq-LU for pgsql-hackers@arkaria.postgresql.org; Sun, 20 Sep 2020 13:45:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kJzeg-0004Cz-IL for pgsql-hackers@arkaria.postgresql.org; Sun, 20 Sep 2020 13:45:26 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kJzeg-00049c-B5 for pgsql-hackers@lists.postgresql.org; Sun, 20 Sep 2020 13:45:26 +0000 Received: from forward1-smtp.messagingengine.com ([66.111.4.223]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kJzec-0000I1-Vh for pgsql-hackers@postgresql.org; Sun, 20 Sep 2020 13:45:25 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailforward.nyi.internal (Postfix) with ESMTP id 3BB0619404B7; Sun, 20 Sep 2020 09:45:20 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 20 Sep 2020 09:45:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=JxS2QJUeUoBXui5wnQdHv91RO3ZSqFAx+vVT/tiy/ Ug=; b=XHNBxxNtj4BrTembogiK8A61ZO/rutwCbNxwMmYTp/sxXFJH/FVYVzUij 8YRaIXwLMF/aUiw/nt1yCsQm3V75t4p0ccADYunOlaretxEbnQJHvzFwZUoUL7/G pV7DD7emjOd/lQ8ZBgAVzXGr1YdOuJ6F8l95xqHGRi+TcMirwuuJVqzk1gXO7UO9 c3tVmJO5RZ7w2jykj08fkYn0pJipb/DqBC+xOTH3PqdB//Iwdc3rk6NvhurnEpS0 WbrzqponINqLsUhsqlWzylrwlPdTj7gPBQcDde7XtxkAmy5AvvpJsLksMvvlN8Yz Upfrkb4jkp7ziXXMA6caRKodpmVPg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddtgdeijecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhfhokffffgggjggtgfesthejredttdefjeenucfhrhhomheprfgvthgv rhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdrvghishgvnhhtrhgruhhtsedvnhguqh hurggurhgrnhhtrdgtohhmqeenucggtffrrghtthgvrhhnpedtveeghedtjedvvedvleej ueevjeejtdellefgkeelfeeikeejlefgkedtudeuvdenucffohhmrghinhepvdhnughquh grughrrghnthdrtghomhenucfkphepkeejrddujeejrdeigedrudeludenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvghrrdgvihhsvg hnthhrrghuthesvdhnughquhgrughrrghnthdrtghomh X-ME-Proxy: Received: from april.pezone.net (p57b140bf.dip0.t-ipconnect.de [87.177.64.191]) by mail.messagingengine.com (Postfix) with ESMTPA id E782F3280059; Sun, 20 Sep 2020 09:45:18 -0400 (EDT) Subject: Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers To: Amit Kapila References: <36aa8aea-61b7-eb3c-263b-648e0cb117b7@2ndquadrant.com> <5a8b1b58-30b6-cd9a-5a37-75f1da063429@2ndquadrant.com> Cc: pgsql-hackers From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: <4de14d71-7fe9-fa12-121e-a41bd610998e@2ndquadrant.com> Date: Sun, 20 Sep 2020 15:46:29 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-09-19 13:24, Amit Kapila wrote: >> I think the implemented behavior is wrong. > > It is the same as what we do for other parallel operations, for > example, we limit the number of parallel workers for parallel create > index by 'max_parallel_maintenance_workers' and parallel scan > operations are limited by 'max_parallel_workers_per_gather'. But in those cases we don't provide user-visible options to specify a per-command setting, so it's not the same thing, is it? >> The VACUUM PARALLEL option >> should override the max_parallel_maintenance_worker setting. >> >> Otherwise, what's the point of the command option? > > It is for the cases where the user has a better idea of workload. We > can launch only a limited number of parallel workers > 'max_parallel_workers' in the system, so sometimes users would like to > use it as per their requirement. Right, but my point is, it doesn't actually do that correctly. I can't just say, oh, I have a maintenance window, I'd like to run a really fast VACUUM. The PARALLEL option is capped by the setting you'd normally use anyway, so specifying it is useless. The only thing it can do right now is if you want to run a manual VACUUM less parallel than by default. But I don't see how that is often useful. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services