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.
