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.96) (envelope-from ) id 1w26YX-000stP-0x for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Mar 2026 11:56:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w26YU-009jtT-33 for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Mar 2026 11:56:19 +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.96) (envelope-from ) id 1w26YU-009jtJ-2A for pgsql-hackers@lists.postgresql.org; Mon, 16 Mar 2026 11:56:19 +0000 Received: from forward102b.mail.yandex.net ([2a02:6b8:c02:900:1:45:d181:d102]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w26YQ-000000000Sz-3pOz for pgsql-hackers@postgresql.org; Mon, 16 Mar 2026 11:56:18 +0000 Received: from mail-nwsmtp-smtp-production-main-69.iva.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-69.iva.yp-c.yandex.net [IPv6:2a02:6b8:c0c:3293:0:640:fd7e:0]) by forward102b.mail.yandex.net (Yandex) with ESMTPS id DCC04C0125; Mon, 16 Mar 2026 14:56:12 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-69.iva.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id 8uJ47S0GoOs0-c6T9C8ht; Mon, 16 Mar 2026 14:56:12 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1773662172; bh=CJp7awA5+K10HABeZZCqtUaAQuxqukyR0jmBIumMCbs=; h=From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID; b=c4F77R/sU/jWZzIhYcIornQrBgHi0uM/2Uu97tjUQifLm4e4+0Ho0n5VGr6qyUF2o ZugZzdpjQXNzxDVAi4+njAnp+BUaSFpywRJTPB6jN71V4eZEUFOT5IR8wLDMrRlOaZ j7bAnTSBaTKlQDyMI3wpTrDTQuN7+8nr3dtRq+GU= Authentication-Results: mail-nwsmtp-smtp-production-main-69.iva.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <877b2c60-6681-4471-ba72-86153f0b9286@yandex.ru> Date: Mon, 16 Mar 2026 15:11:06 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Vacuum statistics To: Andrei Lepikhov , Andrey Borodin Cc: pgsql-hackers , Alexander Korotkov , Amit Kapila , Jim Nasby , Bertrand Drouvot , Kirill Reshke , Andrei Zubkov , Masahiko Sawada , Melanie Plageman , jian he , Sami Imseih , vignesh C , Ilia Evdokimov References: <86f76aa5-1ab5-4e2e-9b15-405051852a2a@postgrespro.ru> <18169b68-5b10-40fd-9657-be04f2bd0161@postgrespro.ru> <612819ad-beca-41fb-bb7f-d5a7c11f0045@yandex.ru> <277ce149-4333-463d-bad6-ccd785606c7f@yandex.ru> <3f9c57bc-dc1f-4ad8-a2e1-5be15ac79264@yandex.ru> <77f1b8bc-b365-4e88-b87b-ced37fabbbf0@yandex.ru> <7a74d6af-85e2-4b48-9133-61309a965954@yandex.ru> <1885f257-46cc-4b90-8d90-41833eb62ea9@gmail.com> <0e84acdc-ba65-44fa-be1f-4d6a86bca2ac@yandex.ru> <8bd78e04-6efa-4fcf-b157-8ac3b92375c8@yandex.ru> <10BE6E39-94D2-4909-ACB8-24E1FA6580EE@yandex-team.ru> Content-Language: en-US From: Alena Rybakina 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 16.03.2026 11:45, Andrei Lepikhov wrote: > On 15/3/26 18:18, Andrey Borodin wrote: >>> On 13 Mar 2026, at 18:04, Alena Rybakina >>> wrote: >> >> I've decided to take a look into v31. >> >> Overall idea of tracking VM dynamics seems good to me. >> >> But the column naming for rev_all_visible_pages and rev_all_frozen_pages >> seems strange to me. I've skimmed the thread but could not figure out >> what >> "rev_" stands for. Revisions? Revolutions? Reviews? > > I suppose 'revert' is the exact term here. Someone decided to set the > flag, and we reverted his decision. Does this make sense to you? > Anyway, I always leave it in the natives' (and committers') hands. I think renaming them to 'cleared' helps avoid the confusion. I have adopted the names proposed by A. Zubkov in v34. >> Some nits about the code. > > I doubt if we need a test for these parameters - they reflect the > physical structure of the storage and might be unstable. But anyway, > it should be better to live in isolation tests, as similar statistics. > I moved the tests there. Regression tests are unfortunately not an option because the statistics are not stable. If the isolation test turns out to be unstable again, I'll move them back to the TAP tests as I initially implemented, following A. Borodin's suggestion. See the version in the https://www.postgresql.org/message-id/767d28c9-2ae8-43df-9f2e-3e8785075115%40yandex.ru -- ----------- Best regards, Alena Rybakina