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-10-28T21:06:12Z
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
On Tue, Oct 28, 2025 at 12:16:28PM +1300, David Rowley wrote: > I think it's reasonable to want to document how autovacuum prioritises > tables, but maybe not in too much detail. Longer term, I think it > would be good to have a pg_catalog view for this which showed the > relid or schema/relname, and the output values of > relation_needs_vacanalyze(). If we had that and we documented that > autovacuum workers work from that list, but they just may have an > older snapshot of it, then that might help make the score easier to > document. It would also allow people to question the scores as I > expect at least some people might not agree with the priorities. That > would allow us to consider tuning the score calculation if someone > points out a deficiency with the current calculation. > > Also, longer-term, it also doesn't seem that unreasonable that the > autovacuum worker might want to refresh the tables_to_process once it > finishes a table and if autovacuum_naptime * $value units of time have > passed since it was last checked. That would allow the worker to deal > with and react accordingly when scores have changed significantly > since it last checked. I mean, it might be days between when > autovacuum calculates the scores and finally vacuums the table when > the list is long, of it it was tied up with large tables. Other > workers may have gotten to some of the tables too, so the score may > have dropped, but again made its way above the threshold, but to a > lesser extent. Agreed on both points. -- nathan