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 →
-
Add relallfrozen to pg_class
- 99f8f3fbbc8f 18.0 cited
-
Move wal_buffers_full from PgStat_PendingWalStats to WalUsage
- eaf502747bac 18.0 cited