Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uRXiD-00D8iU-Eb for pgsql-docs@arkaria.postgresql.org; Tue, 17 Jun 2025 14:54:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uRXiB-00AT3A-J9 for pgsql-docs@arkaria.postgresql.org; Tue, 17 Jun 2025 14:54:56 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uRXiB-00AT32-Bt for pgsql-docs@lists.postgresql.org; Tue, 17 Jun 2025 14:54:56 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by makus.postgresql.org with smtp (Exim 4.96) (envelope-from ) id 1uRXi9-002VjC-2k for pgsql-docs@lists.postgresql.org; Tue, 17 Jun 2025 14:54:54 +0000 Received: from [192.168.11.9] (p1696134-ipoe.ipoe.ocn.ne.jp [118.0.93.133]) by oss.nttdata.com (Postfix) with ESMTPSA id 4351E60172; Tue, 17 Jun 2025 23:54:49 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at oss.nttdata.com Message-ID: Date: Tue, 17 Jun 2025 23:54:48 +0900 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Clarify VACUUM FULL exclusion in total_vacuum_time docs Content-Language: en-US To: Robert Treat Cc: "David G. Johnston" , "pgsql-docs@lists.postgresql.org" References: <2ac375d1-591b-4f1b-a2af-f24335567866@oss.nttdata.com> From: Fujii Masao In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2025/06/13 21:09, Robert Treat wrote: > Well, I admit I mostly mentioned it because when I noticed this one > wasn't documented the same way the other ones were, I second-guessed > myself about if I knew how it really behaved and did a quick test to > confirm :-) > I suspect others might have similar confusion. Maybe I failed to follow your point here... Are you suggesting it's worth mentioning that n_ins_since_vacuum doesn't count VACUUM FULL, to help avoid potential user confusion? If so, since n_ins_since_vacuum was introduced in v13, we'd need to backpatch that documentation change to v13? As for total_vacuum_time, since it's new in v18, I'd like to apply the proposed change there. Regards, -- Fujii Masao NTT DATA Japan Corporation