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
