Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hGUFr-0003Lq-B4 for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Apr 2019 20:00:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hGUFq-0004wi-2g for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Apr 2019 20:00:30 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hGUFp-0004wT-PF for pgsql-hackers@lists.postgresql.org; Tue, 16 Apr 2019 20:00:29 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hGUFm-0007LL-5k for pgsql-hackers@postgresql.org; Tue, 16 Apr 2019 20:00:27 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x3GK0Fhd007520; Tue, 16 Apr 2019 16:00:15 -0400 From: Tom Lane To: Andres Freund cc: Robert Haas , Masahiko Sawada , Kyotaro HORIGUCHI , "Bossart, Nathan" , Alvaro Herrera , PostgreSQL-development Subject: Re: New vacuum option to do only freezing In-reply-to: <31782.1555433074@sss.pgh.pa.us> References: <15751.1555256860@sss.pgh.pa.us> <16814.1555348381@sss.pgh.pa.us> <23885.1555357618@sss.pgh.pa.us> <28991.1555376836@sss.pgh.pa.us> <30116.1555430496@sss.pgh.pa.us> <20190416161019.esqg4zj3xm3kjyxy@alap3.anarazel.de> <31782.1555433074@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Tue, 16 Apr 2019 12:44:34 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7518.1555444815.1@sss.pgh.pa.us> Date: Tue, 16 Apr 2019 16:00:15 -0400 Message-ID: <7519.1555444815@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk I wrote: > I'm thinking that we really need to upgrade vacuum's reporting totals > so that it accounts in some more-honest way for pre-existing dead > line pointers. The patch as it stands has made the reporting even more > confusing, rather than less so. Here's a couple of ideas about that: 1. Ignore heap_page_prune's activity altogether, on the grounds that it's just random chance that any cleanup done there was done during VACUUM and not some preceding DML operation. Make tups_vacuumed be the count of dead line pointers removed. The advantage of this way is that tups_vacuumed would become independent of previous non-VACUUM pruning activity, as well as preceding index-cleanup-disabled VACUUMs. But maybe it's hiding too much information. 2. Have heap_page_prune count, and add to tups_vacuumed, only HOT tuples that it deleted entirely. The action of replacing a DEAD root tuple with a dead line pointer doesn't count for anything. Then also add the count of dead line pointers removed to tups_vacuumed. Approach #2 is closer to the way we've defined tups_vacuumed up to now, but I think it'd be more realistic in cases where previous pruning or index-cleanup-disabled vacuums have left lots of dead line pointers. I'm not especially wedded to either of these --- any other ideas? regards, tom lane