Re: Add pg_stat_autovacuum_priority
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Sami Imseih <samimseih@gmail.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Robert Treat <rob@xzilla.net>, satyanarlapuram@gmail.com, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-04-03T16:47:40Z
Lists: pgsql-hackers
Attachments
- v8-0001-refactor-relation_needs_vacanalyze.patch (text/plain)
On Wed, Apr 01, 2026 at 06:04:36PM -0500, Sami Imseih wrote: > Thanks! here is v7 Alright, I've been preparing these for commit. Most changes are cosmetic, but there are a couple of bigger ones I should note: * I added a prerequisite patch for relation_needs_vacanalyze() that saves a level of indentation on a chunk of code. This simplifies 0001 (now 0002) a bit. * I noticed that if autovacuum decides to force a vacuum for anti-wraparound purposes, it might also decide to analyze the table even if autovacuum is disabled for it. AFAICT this is accidental, but since it's behaved this way since commit 48188e1621 (2006) [0], I am slightly worried that this bug may have become a feature. In 0002, I separated this edge case in the code and added a comment, and I intend to start a new thread about removing it. * I removed the booleans in the view in favor of just noting that scores >= 1.0 means the table needs processing. IMHO trying to distinguish needs_vacuum from do_vacuum is just going to confuse folks more than anything, and IIUC this information is redundant with "score >= 1.0", anyway. * I renamed the view to pg_autovacuum_scores. While some of the information in the view depends on cumulative statistics, not all of it does, and what does is quite heavily modified from the original stats. So, I didn't think the pg_stat_* prefix was appropriate, although I can see how reasonable people might disagree. * I considered whether to make the backing function per-table and ultimately decided against it. The initialization logic is a bit expensive, and I assume most folks will be interested in the full picture of the current database. Maybe we could add a per-table function down the road, but I don't see any strong need for that for now. I'm planning to commit 0001-0004 this afternoon, assuming cfbot is happy. I'm hoping to commit 0005 on Monday or Tuesday. Please take a look at v8 if you have time. [0] https://postgr.es/m/23710.1162661716%40sss.pgh.pa.us -- nathan
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix double-free in pg_stat_autovacuum_scores.
- 71ff232a5bc4 19 (unreleased) landed
-
Add LOG_NEVER error level code.
- 60165db6e1f2 19 (unreleased) landed
-
Add pg_stat_autovacuum_scores system view.
- 87f61f0c8280 19 (unreleased) landed
-
Remove recheck_relation_needs_vacanalyze().
- 775fe51daaef 19 (unreleased) landed
-
Add elevel parameter to relation_needs_vacanalyze().
- 01876ace1369 19 (unreleased) landed
-
Teach relation_needs_vacanalyze() to always compute scores.
- 53b8ca6881a1 19 (unreleased) landed
-
Refactor relation_needs_vacanalyze().
- 8261ee24fe33 19 (unreleased) landed
-
Add rudimentary table prioritization to autovacuum.
- d7965d65fc5b 19 (unreleased) cited
-
Fix per-relation memory leakage in autovacuum.
- 02502c1bca54 18.0 cited
-
Fix recently-understood problems with handling of XID freezing, particularly
- 48188e1621bb 8.2.0 cited