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 1mFdD9-00073L-Pq for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Aug 2021 14:03:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mFdD8-0000l0-Cu for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Aug 2021 14:03:30 +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 1mFdD8-0000ks-4s for pgsql-hackers@lists.postgresql.org; Mon, 16 Aug 2021 14:03:30 +0000 Received: from new1-smtp.messagingengine.com ([66.111.4.221]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mFdD5-0008QJ-3I for pgsql-hackers@lists.postgresql.org; Mon, 16 Aug 2021 14:03:29 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id AF35D580464; Mon, 16 Aug 2021 10:03:24 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 16 Aug 2021 10:03:24 -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=ZbTA2aDFNDrdDcpjNSgxkFXGJjJIy6u82HnwJb1ILIk=; b=BHbMsswT xMZ7kRwq9r6TSg0a2CXpnQkrFtioA0ie0qVYwJ5lDAZgqEACvmQA13GvCoNl7f7i TlG8BCQtViaih4qj3KWrRit+cz92fUjOk+/wUTnQ/gXzo/uy+pg22QgXTzKgpVi4 Vtvu05TIZTzqVWHxdelpsvh8VEoPAAH4CHGXh9aRMdbYxicwMbll+UcsSqU7UXD4 icOoqdtFpbaUPRqvQ6VbVeW4HX0Xk12ZEdkZ6U7wdYuUqG98luYZ1LIOuY7C2d/j e2BKWf0wIUuFohRmYmD7FEe5Gd1ao51X3uUQIm1fqjlzxzhzmHmnl7YdnSsiGcLg 2HpZ0awz78KvKQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrledugdejudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkgggtugfgjgesthekredttddtjeenucfhrhhomheplmhlvhgrrhho ucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgheqne cuggftrfgrthhtvghrnhepudevgeetieeiheefudevveefgeejieejtdevteekkeelgffg leegteehvdduteegnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomhenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgv rhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 16 Aug 2021 10:03:21 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 2DB032A099B; Mon, 16 Aug 2021 10:03:18 -0400 (-04) Date: Mon, 16 Aug 2021 10:03:18 -0400 From: =?utf-8?Q?=C3=81lvaro?= Herrera To: Andres Freund Cc: Kyotaro HORIGUCHI , yuzuko , Tomas Vondra , David Steele , Kyotaro Horiguchi , Justin Pryzby , Daniel Gustafsson , Amit Langote , Masahiko Sawada , Laurenz Albe , "pgsql-hackers@lists.postgresql.org" , Greg Stark Subject: Re: Autovacuum on partitioned table (autoanalyze) Message-ID: <202108161403.moxi73uz5zzf@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0794d7ca-5183-486b-9c5e-6d434867cecd@www.fastmail.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021-Aug-13, Álvaro Herrera wrote: > Some doc changes are pending, and some more commentary in parts of the > code, but I think this is much more sensible. I do lament the lack of > a syscache for pg_inherits. Thinking about this again, this one here is the killer problem, I think; this behaves pretty horribly if you have more than one partition level, because it'll have to do one indexscan *per level per partition*. (For example, five partitions two levels down mean ten index scans). There's no cache for this, and no way to disable it. So for situations with a lot of partitions, it could be troublesome. Granted, it only needs to be done for partitions with DML changes since the previous autovacuum worker run in the affected database, but still it could be significant. Now we could perhaps have a hash table in partition_analyze_report_ancestors() to avoid the need for repeated indexscans for partitions of the same hierarchy (an open-coded cache to take the place of the missing pg_inherits syscache); and perhaps even use a single seqscan of pg_inherits to capture the whole story first and then filter down to the partitions that we were asked to process ... (so are we building a mini-optimizer to determine which strategy to use in each case?). That all sounds too much to be doing in the beta. So I'm leaning towards the idea that we need to revert the patch and start over for pg15. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "La libertad es como el dinero; el que no la sabe emplear la pierde" (Alvarez)