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 1lTBbP-0004Yr-0m for pgsql-hackers@arkaria.postgresql.org; Sun, 04 Apr 2021 22:52:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lTBbN-0002rc-Pk for pgsql-hackers@arkaria.postgresql.org; Sun, 04 Apr 2021 22:52:17 +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 1lTBbM-0002rV-VJ for pgsql-hackers@lists.postgresql.org; Sun, 04 Apr 2021 22:52:17 +0000 Received: from [66.111.4.221] (helo=new1-smtp.messagingengine.com) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lTBbJ-0006QD-Qj for pgsql-hackers@lists.postgresql.org; Sun, 04 Apr 2021 22:52:15 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 918DE580220; Sun, 4 Apr 2021 18:52:02 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sun, 04 Apr 2021 18:52:02 -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=ch/tWAnc6wg2r1rsQcmrng0q5E/WzTZ4uxPfyYeuZ80=; b=lIBwTEsf Wt/RqmIbogjTVnLbpv9I1QR4X5RgLbznxUTGVcxC7EH539i3yLs65khYbjlwSlXp +1TvGCyKVOL2JcGtUT4TTYspjcsZ0l0O3+VF8LnwA1/4aKc3d3znvCUOC3hS31yW 4R7/rVrOZDILqAMF185aJogEB1Qjo46QNLg534W3Llv6jz/1xGQmsZlWZEVDQAmm Q1I0x+0lXNGUCb4sld8+WIIcCeIF33mc/asgsyysLZhwEO3Z+FX/LtSxwD2vtCzN zK0WVewfFtBvo2qNdKyvomPAE1FxA0+kQSVJ42PbBEtEqF0Uyqvw/8lsLNEhC4FH LQxfF+5yGv9i5Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudejuddgudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjfgesthekredttderudenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepveejjeekjeejieevueduvdefffeihfffgfelhefgueeg jeehuddvfeekiefhffdtnecuffhomhgrihhnpehpohhsthhgrhgvshhqlhdrohhrghenuc fkphepudeltddrleehrdduledrleehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomheprghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.19.95]) by mail.messagingengine.com (Postfix) with ESMTPA id D464C1080057; Sun, 4 Apr 2021 18:52:00 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id F21912A0D53; Sun, 4 Apr 2021 18:51:58 -0400 (-04) Date: Sun, 4 Apr 2021 18:51:58 -0400 From: Alvaro Herrera To: Tomas Vondra Cc: yuzuko , 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: <20210404225158.GA22303@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Host-Lookup-Failed: Reverse DNS lookup failed for 66.111.4.221 (deferred) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021-Apr-04, Tomas Vondra wrote: > In fact, one of the first posts in this threads links to this: > > https://www.postgresql.org/message-id/4823.1262132964%40sss.pgh.pa.us > > i.e. Tom actually proposed doing something like this back in 2009, so > presumably he though it's desirable back then. > > OTOH he argued against adding another per-table counter and proposed > essentially what the patch did before, i.e. propagating the counter > after analyze. But we know that may trigger analyze too often ... Yeah, I think that's a doomed approach. The reason to avoid another column is to avoid bloat, which is good but if we end up with an unworkable design then we know we have to backtrack on it. I was thinking that we could get away with having a separate pgstat struct for partitioned tables, to avoid enlarging the struct for all tables, but if we're going to also include legacy inheritance in the feature clearly that doesn't work. -- Álvaro Herrera Valdivia, Chile "After a quick R of TFM, all I can say is HOLY CR** THAT IS COOL! PostgreSQL was amazing when I first started using it at 7.2, and I'm continually astounded by learning new features and techniques made available by the continuing work of the development team." Berend Tober, http://archives.postgresql.org/pgsql-hackers/2007-08/msg01009.php