Message-ID: <7a74d6af-85e2-4b48-9133-61309a965954@yandex.ru>
Date: Thu, 12 Mar 2026 21:10:49 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Vacuum statistics
To: Andrei Lepikhov <lepihov@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: Alexander Korotkov <aekorotkov@gmail.com>,
 Amit Kapila <amit.kapila16@gmail.com>, Jim Nasby <jnasby@upgrade.com>,
 Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
 Kirill Reshke <reshkekirill@gmail.com>, Andrei Zubkov <zubkov@moonset.ru>,
 Masahiko Sawada <sawada.mshk@gmail.com>,
 Melanie Plageman <melanieplageman@gmail.com>,
 jian he <jian.universality@gmail.com>, Sami Imseih <samimseih@gmail.com>,
 vignesh C <vignesh21@gmail.com>,
 Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
References: <86f76aa5-1ab5-4e2e-9b15-405051852a2a@postgrespro.ru>
 <e66086a1-641a-4758-b3fc-5e92c74c9239@postgrespro.ru>
 <5583261b-eede-4341-b3b1-91650fefc1cf@postgrespro.ru>
 <2a04ad18-5572-4633-848b-eb57209e7ac0@postgrespro.ru>
 <CAA4eK1JOUn+EqWSfRgKfgBZOXT7Q2dw2enmSZZgOhoMOFwopPA@mail.gmail.com>
 <2f48399f-2959-4483-938f-64edb863ca76@postgrespro.ru>
 <CAPpHfdtQd29O15Cmp1qeqTCerQF0Y+BGh63qtX3RkA7k=0TZ1Q@mail.gmail.com>
 <18169b68-5b10-40fd-9657-be04f2bd0161@postgrespro.ru>
 <cb205605-d24c-41a3-9205-fe59e13af9ed@postgrespro.ru>
 <f5097647-89f9-4288-9010-9f690778dd53@postgrespro.ru>
 <c43ef413-f65b-46a5-b8a1-28949daaa889@tantorlabs.com>
 <612819ad-beca-41fb-bb7f-d5a7c11f0045@yandex.ru>
 <de4bdbff-a86c-4830-82b1-0c14af2b597d@postgrespro.ru>
 <277ce149-4333-463d-bad6-ccd785606c7f@yandex.ru>
 <3f9c57bc-dc1f-4ad8-a2e1-5be15ac79264@yandex.ru>
 <77f1b8bc-b365-4e88-b87b-ced37fabbbf0@yandex.ru>
 <a6450303-30fe-4d6e-b31a-055dccf09a2b@gmail.com>
 <f4d067c7-8e3e-451a-b13e-28a08b3b871f@gmail.com>
Content-Language: en-US
From: Alena Rybakina <lena.ribackina@yandex.ru>
In-Reply-To: <f4d067c7-8e3e-451a-b13e-28a08b3b871f@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/7a74d6af-85e2-4b48-9133-61309a965954%40yandex.ru>
Precedence: bulk

On 12.03.2026 18:28, Andrei Lepikhov wrote:

>
> In addition, it makes sense to discuss how these parameters are 
> supposed to be used. I see the following use cases:
>
> 1. Which tables have the most VM churn? - monitoring 
> rev_all_visible_pages normalised on the table size and its average 
> tuple width might expose the most suspicious tables (in terms of table 
> statistics).
> 2. DML Skew. Dividing rev_all_visible_pages by the number of tuple 
> updates/deletes, normalised by the average table and tuple sizes, 
> might indicate whether changes are localised within the table.
> 3. IndexOnlyScan effectiveness. Considering the speed of 
> rev_all_visible_pages change, normalised to the value of the 
> relallvisible statistic, we may detect tables where Index-Only Scan 
> might be inefficiently used.
>
>
I agree with all these points and I think we can add it in the 
documentation.

On 12.03.2026 17:02, Andrei Lepikhov wrote:
> On 9/3/26 16:46, Alena Rybakina wrote:
>> I discovered that my last patches were incorrectly formed. I updated 
>> the correct version.
>
> I see that v29-0001-* is a quite separate feature itself at the 
> moment. It makes sense to remove the commit message phrase for 
> vm_new_frozen_pages and vm_new_visible_pages, introduced in later 
> patches.
> This patch itself looks good to me. 

BTW, I have noticed that my third patch (from 29th - when I have added 
ext_vacuum_statistics) is huge but I have no idea how to split it 
logically. I'm not sure that separation by objects can simplify the 
review process. Maybe I should add only base logic for the extension and 
then gucs, what do you think?

Any suggestions are welcome here.