Re: Vacuum statistics
Andrei Lepikhov <lepihov@gmail.com>
From: Andrei Lepikhov <lepihov@gmail.com>
To: Alena Rybakina <lena.ribackina@yandex.ru>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: 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>, Andrei Zubkov <zubkov@moonset.ru>,
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-12T13:28:42Z
Lists: pgsql-hackers
Attachments
- v30-0001-Track-table-VM-stability.patch (text/plain) patch v30-0001
On 12/3/26 13:02, Andrei Lepikhov wrote: > On 9/3/26 16:46, Alena Rybakina wrote: >> I discovered that my last patches were incorrectly formed. I updated >> the correct version. > > I see that v29-0001-* is a quite separate feature itself at the moment. > It makes sense to remove the commit message phrase for > vm_new_frozen_pages and vm_new_visible_pages, introduced in later patches. > This patch itself looks good to me. Since this patch is almost ready for commit, I reviewed it carefully. I noticed a documentation entry was missing, so I added it. Please see the attachment. While updating the patch file, I also made a few small adjustments, including changing the parameter order in the struct and VIEW. The commit message is also fixed. In addition, it makes sense to discuss how these parameters are supposed to be used. I see the following use cases: 1. Which tables have the most VM churn? - monitoring rev_all_visible_pages normalised on the table size and its average tuple width might expose the most suspicious tables (in terms of table statistics). 2. DML Skew. Dividing rev_all_visible_pages by the number of tuple updates/deletes, normalised by the average table and tuple sizes, might indicate whether changes are localised within the table. 3. IndexOnlyScan effectiveness. Considering the speed of rev_all_visible_pages change, normalised to the value of the relallvisible statistic, we may detect tables where Index-Only Scan might be inefficiently used. Feel free to criticise it or add your own - I’m just a developer, not a DBA. Also, I’m not sure what use cases there are for the rev_all_frozen_pages parameter. -- regards, Andrei Lepikhov, pgEdge
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