Re: Vacuum statistics

Hi!

On 3/16/26 02:27, Alena Rybakina wrote:
>
> Hi Andrey, thank you for taking a look and for the review!
>
+1
>> But the column naming for rev_all_visible_pages and rev_all_frozen_pages
>> seems strange to me. I've skimmed the thread but could not figure out what
>> "rev_" stands for. Revisions? Revolutions? Reviews?
>
> We meant "revision", but after looking at our documentation I realized
> the confusion - the term is not explained there.
>
> I've renamed them to visible_pages_vm_cleared and frozen_pages_vm_cleared.
>
> Does this naming make more sense?
>
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_".

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.

--

best regards, Andrei Zubkov

Postgres Professional