Re: Vacuum statistics

Hi! Thank you for your attention to this patch!

On 16.03.2026 11:34, Андрей Зубков wrote:
> Really it was "revocations", but I'm agree with Andrey that naming 
> isn't clear. *_vm_cleared looks better, but talking about naming here 
> "vm" meaning is not clear. I think it will be understood as visibility 
> map, but it is "mark" really. Maybe "*_pages_marks_cleared" will be 
> better?
>
> Also a macro in pgstat.h:733 and pgstat.h:738 still holds "_rev_".
Good catch, fixed.
>
> I think the docs description needs a little correction:
>
> - visible_pages_vm_cleared. I think listing of possible DML operations
>   is not needed here, also it seems a high rate of this counter has no
>   direct relation to the index only scans because we can have very
>   agressive vacuum on a table that will do the opposite. It will hold
>   few pages without visibility marks constantly but with the cost
>   of high visible_pages_vm_cleared rate. My proposition follows:
>
>   Number of times the all-visible bit in the
>    <link linkend="storage-vm">visibility map</link> was cleared for a
>   pages of this table. The all-visible bit of a heap page is cleared
>   every time backend process modifies a page previously marked
>   all-visible by vacuum. Vacuum process must process page once again
>   on the next run. A high rate of change of this counter means that
>   vacuum should re-do its work on this table.
>
> - frozen_pages_vm_cleared:
>
>   Number of times the all-frozen bit in the
>    <link linkend="storage-vm">visibility map</link> was cleared for a
>   pages of this table.  The all-frozen bit of a heap page is cleared
>   every time backend process modifies a page previously marked
>   all-frozen by vacuum. Vacuum process must process page once again on
>   the next freeze run on this table.
I agree, this description is clearer. Fixed.

-----------
Best regards,
Alena Rybakina