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 1lgaMe-0007KY-9f for pgsql-hackers@arkaria.postgresql.org; Tue, 11 May 2021 21:56:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lgaMd-0004JS-40 for pgsql-hackers@arkaria.postgresql.org; Tue, 11 May 2021 21:56:27 +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 1lgaMc-0004JG-Sd for pgsql-hackers@lists.postgresql.org; Tue, 11 May 2021 21:56:26 +0000 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lgaMa-0000vP-KF for pgsql-hackers@lists.postgresql.org; Tue, 11 May 2021 21:56:26 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 7526A179C; Tue, 11 May 2021 17:56:20 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 11 May 2021 17:56: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:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=4gTSZckql7MpjIfYXv8YGT9/WDsG8yfZQOF2DZ9LQcg=; b=Tuz3o8XG RllaGozjY+Q35/CFa/zgYZZUZrWPy354xKS7EgYTvtdTBTEVDPm/Gu9akAHWDfdb 6mJmzYuHPZ6l11wK8zcdhn232eEwC5OjkBarKQ9lq5x4U28tbd04WNHlTdOBDT8S yVkjq/D0+Wqkd7vpEPaMQDPTbMUTZ4TB0H2ArLGNsIBS7tT8LtWFYqt8rAvTKCJW 2CfcKvhJU3m/Y74oZtvyuB7QbuB5HPlaisCYnrwLO2fqD7W8Y3NkOOK+FhClktjN 4tIR5RxXwwLAyJoI9Q1UJgI4nrNZ1sUjtdGSm3sVYNAm2nA4S9p3MCP4coKXt/BQ vOFD5gql1obEWg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdehuddgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjfgesmhekreertderudenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhephfefgeelkefgjeeuhefgfeevleeftedvhefftdeutefg hfekhfduheffkeduteeknecukfhppeduledtrdelhedrudelrdelheenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvgesrghl vhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.19.95]) by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 11 May 2021 17:56:18 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 619C22A0BB7; Tue, 11 May 2021 17:56:16 -0400 (-04) Date: Tue, 11 May 2021 17:56:16 -0400 From: Alvaro Herrera To: Justin Pryzby Cc: Robert Haas , Tom Lane , Zhihong Yu , pgsql-hackers@lists.postgresql.org Subject: Re: pgsql: autovacuum: handle analyze for partitioned tables Message-ID: <20210511215616.GA13282@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210423180152.GA17270@telsasoft.com> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On 2021-Apr-23, Justin Pryzby wrote: > On Thu, Apr 22, 2021 at 12:43:46PM -0500, Justin Pryzby wrote: > > > > I think that should probably have been written down somewhere other than for > > the manual ANALYZE command, but in any case it seems to be outdated now. > > Starting with this Agreed, we need some more docs here. I lightly edited yours and ended up with this -- mostly I think partitioned tables should not be in the same paragraph as legacy inheritance because the behavior is different enough (partitioned tables are not analyzed twice). I'll give a deeper look tomorrow to see if other places also need edits. Thanks -- Álvaro Herrera Valdivia, Chile --NzB8fVQJ5HfG6fxh Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="autoanalyze-doc.patch" diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml index 89ff58338e..ddd6c3ff3e 100644 --- a/doc/src/sgml/perform.sgml +++ b/doc/src/sgml/perform.sgml @@ -1767,7 +1767,8 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse; Whenever you have significantly altered the distribution of data within a table, running ANALYZE is strongly recommended. This - includes bulk loading large amounts of data into the table. Running + includes bulk loading large amounts of data into the table as well as + attaching, detaching or dropping partitions. Running ANALYZE (or VACUUM ANALYZE) ensures that the planner has up-to-date statistics about the table. With no statistics or obsolete statistics, the planner might diff --git a/doc/src/sgml/ref/analyze.sgml b/doc/src/sgml/ref/analyze.sgml index c8fcebc161..9d5e2a9626 100644 --- a/doc/src/sgml/ref/analyze.sgml +++ b/doc/src/sgml/ref/analyze.sgml @@ -250,7 +250,17 @@ ANALYZE [ VERBOSE ] [ table_and_columns - If the table being analyzed has one or more children, + If the table being analyzed is partitioned, ANALYZE + will gather statistics by scanning all of its partitions. + The autovacuum daemon counts inserts and updates in the partitions + to determine if auto-analyze is needed. However, adding or + removing partitions does not affect the autovacuum daemon decisions, + so triggering a manual ANALYZE is recommended when + they occur. + + + + If the table being analyzed has one or more legacy inheritance children, ANALYZE will gather statistics twice: once on the rows of the parent table only, and a second time on the rows of the parent table with all of its children. This second set of statistics @@ -263,7 +273,7 @@ ANALYZE [ VERBOSE ] [ table_and_columns - If any of the child tables are foreign tables whose foreign data wrappers + If any of the child tables or partitions are foreign tables whose foreign data wrappers do not support ANALYZE, those child tables are ignored while gathering inheritance statistics. diff --git a/doc/src/sgml/ref/pg_restore.sgml b/doc/src/sgml/ref/pg_restore.sgml index 93ea937ac8..474f18c73f 100644 --- a/doc/src/sgml/ref/pg_restore.sgml +++ b/doc/src/sgml/ref/pg_restore.sgml @@ -922,8 +922,10 @@ CREATE DATABASE foo WITH TEMPLATE template0; Once restored, it is wise to run ANALYZE on each - restored table so the optimizer has useful statistics; see - and + restored table so the optimizer has useful statistics. + If the table is a partition or an inheritance child, it may also be useful + to analyze the parent table. + See and for more information. --NzB8fVQJ5HfG6fxh--