Re: Vacuum statistics

On 13.03.2026 15:51, Alena Rybakina 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.
>>
>> With the parameter that was included before (pg_class_relallfrozen 
>> and relallvisible 
>> https://github.com/MasaoFujii/postgresql/commit/99f8f3fbbc8f743290844e8c676d39dad11c5d5d) 
>> in the pg_stat_tables, I think I can provide isolation test to prove 
>> it - I can use my isolation test 
>> vacuum-extending-in-repetable-read.spec that I have added in the 
>> extension (ext_vacuum_statistics). What do you think? 
>
> I've prepared the test. Do you think it would make sense to include it 
> in 0001?
>
I have added it in the 31th version for now and nothing else has been 
changed (if you don't mind, exclude it).