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.
