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
