Re: Vacuum statistics

Andrei Zubkov <zubkov@moonset.ru>

From: Андрей Зубков <zubkov@moonset.ru>
To: Alena Rybakina <lena.ribackina@yandex.ru>, Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Andrei Lepikhov <lepihov@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Alexander Korotkov <aekorotkov@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Jim Nasby <jnasby@upgrade.com>, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Kirill Reshke <reshkekirill@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Melanie Plageman <melanieplageman@gmail.com>, jian he <jian.universality@gmail.com>, Sami Imseih <samimseih@gmail.com>, vignesh C <vignesh21@gmail.com>, Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
Date: 2026-03-16T08:34:04Z
Lists: pgsql-hackers
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




Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Add relallfrozen to pg_class

  2. Move wal_buffers_full from PgStat_PendingWalStats to WalUsage