Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sbYWy-00HQCf-5r for pgsql-general@arkaria.postgresql.org; Wed, 07 Aug 2024 04:44:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sbYWw-004W8U-Ct for pgsql-general@arkaria.postgresql.org; Wed, 07 Aug 2024 04:44:10 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sbYWw-004W8M-2D for pgsql-general@lists.postgresql.org; Wed, 07 Aug 2024 04:44:10 +0000 Received: from smtp119.iad3b.emailsrvr.com ([146.20.161.119]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sbYWt-003ZYe-TL for pgsql-general@lists.postgresql.org; Wed, 07 Aug 2024 04:44:09 +0000 X-Auth-ID: xof@thebuild.com Received: by smtp7.relay.iad3b.emailsrvr.com (Authenticated sender: xof-AT-thebuild.com) with ESMTPSA id 13737600BF; Wed, 7 Aug 2024 00:44:05 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: ANALYZE on partitioned tables vs on individual partitions From: Christophe Pettus In-Reply-To: Date: Tue, 6 Aug 2024 21:43:35 -0700 Cc: pgsql-general@lists.postgresql.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Michael Harris X-Mailer: Apple Mail (2.3774.600.62) X-Classification-ID: 364ccbcc-3c89-406b-aaf8-d07325fdf29e-1-1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On Aug 6, 2024, at 21:13, Michael Harris wrote: >=20 > 1. What is the consequence of not having good statistics on = partitioned table level, if you do have good statistics on the partition = level? The child partitions are just tables, and all of the same issues that = can arise from bad statistics on a table can arise on them: = specifically, bad query plans. (There are also some consequences to = leaving a table unvacuumed, even an append-only table.) The root table = in declarative partitioning has no rows, so there really is no such = thing as "statistics at the partition level." > 2. Which planning operations rely on partitioned table level = statistics? Just about every query uses the information that ANALYZE gathers in some = way. If the query can't be executed in any other conceivable way than a = sequential scan, or if it is a simple lookup on a unique column, the = statistics will not contribute to the plan, but essentially every other = plan will use them in one way or another. Child partitions should be autovacuumed and autoanalyzed just like any = other table; they are not prohibited from autovacuum in any way by = default. It's probably a good idea to investigate why they are not = being picked up by autovacuum. If they are created by a bulk load = process, it's not a bad idea to do a VACUUM ANALYZE on them once the = bulk load is complete.=