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 1k3lIh-0002j9-Ky for pgsql-hackers@arkaria.postgresql.org; Thu, 06 Aug 2020 19:11:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1k3lIf-0000pl-Qo for pgsql-hackers@arkaria.postgresql.org; Thu, 06 Aug 2020 19:11:37 +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 1k3lIf-0000pd-Jy for pgsql-hackers@lists.postgresql.org; Thu, 06 Aug 2020 19:11:37 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k3lIc-0004vH-FM for pgsql-hackers@lists.postgresql.org; Thu, 06 Aug 2020 19:11:36 +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 076JBRNd2638834; Thu, 6 Aug 2020 15:11:27 -0400 From: Tom Lane To: Robert Haas cc: Andres Freund , Alvaro Herrera , James Coleman , pgsql-hackers , Simon Riggs Subject: Re: PROC_IN_ANALYZE stillborn 13 years ago In-reply-to: References: <20200805021435.GA9523@alvherre.pgsql> <20200805235549.GA8118@alvherre.pgsql> <20200806010711.mzvu36zy25xer33t@alap3.anarazel.de> <2637311.1596739058@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Thu, 06 Aug 2020 14:48:52 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2638832.1596741087.1@sss.pgh.pa.us> Date: Thu, 06 Aug 2020 15:11:27 -0400 Message-ID: <2638833.1596741087@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Robert Haas writes: > Not to get too far from the proposal on the table of just removing > something that's been unused for a really long time, which stands on > its own merits, but if a particular ANALYZE doesn't invoke any > user-defined functions and isn't run inside a transaction, could we > skip acquiring a snapshot altogether? That's an extremely common case, > though by no means universal. I'm inclined to think not. (1) Without a snapshot it's hard to make any non-bogus decisions about which tuples are live and which are dead. Admittedly, with Simon's proposal the final totals would be spongy anyhow, but at least the individual decisions produce meaningful answers. (2) I'm pretty sure there are places in the system that assume that any reader of a table is using an MVCC snapshot. For instance, didn't you introduce some such assumptions along with or just after getting rid of SnapshotNow for catalog scans? regards, tom lane