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).