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 1kXqyI-0004Qd-Gq for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Oct 2020 19:18:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kXqyH-0006WB-At for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Oct 2020 19:18:57 +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 1kXqyH-0006W4-42 for pgsql-hackers@lists.postgresql.org; Wed, 28 Oct 2020 19:18:57 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kXqyF-0006vQ-36 for pgsql-hackers@lists.postgresql.org; Wed, 28 Oct 2020 19:18:56 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 09SJIqGe1443543; Wed, 28 Oct 2020 15:18:52 -0400 From: Tom Lane To: Tomas Vondra cc: "David G. Johnston" , =?utf-8?B?RmFicsOtemlv?= Mello , PostgreSQL Hackers Subject: Re: Add important info about ANALYZE after create Functional Index In-reply-to: <20201028191201.wh5ldvhsiqy2vknu@development> References: <20201028185538.fzux2lhim472h46o@development> <20201028191201.wh5ldvhsiqy2vknu@development> Comments: In-reply-to Tomas Vondra message dated "Wed, 28 Oct 2020 20:12:01 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1443541.1603912732.1@sss.pgh.pa.us> Date: Wed, 28 Oct 2020 15:18:52 -0400 Message-ID: <1443542.1603912732@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Tomas Vondra writes: > On Wed, Oct 28, 2020 at 12:00:54PM -0700, David G. Johnston wrote: >> Given how simple the manual workaround is not having it be manual seems >> like it would be safe and straight-forward to implement. > Maybe, but I wouldn't be surprised if it was actually a bit trickier in > practice, particularly for the CONCURRENTLY case. But I haven't tried. > Anyway, I think there's an agreement it'd be valuable to do this after > CREATE INDEX in the future, so if someone wants to implement it that'd > be great. We can consider backpatching only once we have an actual patch > anyway. Just to be clear, I'm entirely *not* on board with that. IMV it's intentional that we do not force auto-analyze activity after CREATE INDEX or CREATE STATISTICS. If we change that, people will want a way to opt out of it, and then your "simple" patch isn't so simple anymore. (Not that it was simple anyway. What if the CREATE is inside a transaction block, for instance? There's no use in kicking autovacuum before commit.) regards, tom lane