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 1mDBUZ-0002aL-4h for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Aug 2021 20:03:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mDBU1-00069p-9h for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Aug 2021 20:02:49 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mDBU0-00068a-3Y for pgsql-hackers@lists.postgresql.org; Mon, 09 Aug 2021 20:02:48 +0000 Received: from new1-smtp.messagingengine.com ([66.111.4.221]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mDBTu-00037L-GA for pgsql-hackers@lists.postgresql.org; Mon, 09 Aug 2021 20:02:47 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 6F42A580A2B; Mon, 9 Aug 2021 16:02:40 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 09 Aug 2021 16:02:40 -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:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=5+DGHE+EUz5be/Wfu0buzagCg7yxgVwMK2InHTPcU2o=; b=dksWkd++ Virnv6BKnPAC1DOs06uc6amDF4PpnHAK+YC/nQR4kcFynNybvHnTOyTaOkTtV/sB 6M+C62t+2cpQAzELuBkkk+xRsm1BhQztFLg8FybQXj0Ra3ck83x9DKbd4pB0Nhs8 8v5v5UaPuybPDKM32lfyCyTfDQDCEgIlA+KnXxsoMO5sK/fdHFXR/hTuBeepfzFV l+kzUYvJDQ50UIqdfkGPMYdeMRocUPPIL5o3D4dH1q1+roLv1Q1Nnku72Ib0qyV8 Afs+vhAVTwWlZKUtbzmiC/bEUtSHxb/u8zx/kgSmz5aiLWVIrlCfE5Vulh7lsVXI OjyGjlNgR4eVAA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrjeejgddugeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpedujeevjeffjeevuddutedvkeeiueeitddvieelfeekveej udefgeeuvdejhfeuleenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 9 Aug 2021 16:02:36 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id C82D12A09B9; Mon, 9 Aug 2021 16:02:33 -0400 (-04) Date: Mon, 9 Aug 2021 16:02:33 -0400 From: Alvaro Herrera To: Andres Freund Cc: Kyotaro HORIGUCHI , yuzuko , Tomas Vondra , David Steele , Kyotaro Horiguchi , Justin Pryzby , Daniel Gustafsson , Amit Langote , Masahiko Sawada , Laurenz Albe , PostgreSQL Hackers , Greg Stark Subject: Re: Autovacuum on partitioned table (autoanalyze) Message-ID: <202108092002.qccmx6sxilfp@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210728022342.brary7sntq4fvsbl@alap3.anarazel.de> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi On 2021-Jul-27, Andres Freund wrote: > Isn't this going to create a *lot* of redundant sampling? Especially if you > have any sort of nested partition tree. In the most absurd case a partition > with n parents will get sampled n times, solely due to changes to itself. It seems to me that you're barking up the wrong tree on this point. This problem you describe is not something that was caused by this patch; ANALYZE has always worked like this. We have discussed the idea of avoiding redundant sampling, but it's clear that it is not a simple problem, and solving it was not in scope for this patch. > Additionally, while analyzing all child partitions for a partitioned tables > are AccessShareLock'ed at once. If a partition hierarchy has more than one > level, it actually is likely that multiple autovacuum workers will end up > processing the ancestors separately. This seems like it might contribute to > lock exhaustion issues with larger partition hierarchies? I agree this seems a legitimate problem. -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/