Re: Vacuum statistics

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.