Re: another autovacuum scheduling thread

Nathan Bossart <nathandbossart@gmail.com>

From: Nathan Bossart <nathandbossart@gmail.com>

To: David Rowley <dgrowleyml@gmail.com>

Cc: Sami Imseih <samimseih@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Jeremy Schneider <schneider@ardentperf.com>, pgsql-hackers@postgresql.org

Date: 2025-11-11T16:36:32Z

Lists: pgsql-hackers

Commits

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

Add rudimentary table prioritization to autovacuum.
- d7965d65fc5b 19 (unreleased) landed
Trigger more frequent autovacuums with relallfrozen
- 06eae9e6218a 18.0 cited
Harden nbtree page deletion.
- c34787f91058 14.0 cited
Check for interrupts inside the nbtree page deletion code.
- 3a01f68e35a3 12.0 cited

Attachments

v8-0001-autovacuum-scheduling-improvements.patch (text/plain)

Still catching up on the latest discussion, but here's a v8 patch that
amends the DEBUG3 in relation_needs_vacanalyze() to also log the score.  I
might attempt to add some sort of brief documentation about autovacuum
prioritization next.

From skimming the latest discussion, I gather we might want to consider
re-sorting the list periodically.  Is the idea that we'll re-sort the
remaining tables in the list, or that we'll basically restart
do_autovacuum()?  If it's the latter, then we'll need to come up with some
way to decide when to stop for the current database.  Right now, we just go
through pg_class and call it a day.

-- 
nathan