Re: Introduce some randomness to autovacuum
Junwang Zhao <zhjwpku@gmail.com>
From: Junwang Zhao <zhjwpku@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-05-01T05:35:36Z
Lists: pgsql-hackers
On Thu, May 1, 2025 at 8:12 AM David Rowley <dgrowleyml@gmail.com> wrote: > > On Thu, 1 May 2025 at 03:29, Nathan Bossart <nathandbossart@gmail.com> wrote: > > That being said, I am -1 for this proposal. Autovacuum parameters and > > scheduling are already quite complicated, and making it nondeterministic > > would add an additional layer of complexity (and may introduce its own > > problems). But more importantly, IMHO it masks the problems instead of > > solving them more directly, and it could mask future problems, too. It'd > > probably behoove us to think about the known problems more deeply and to > > craft more targeted solutions. > > -1 from me too. > > It sounds like the aim is to fix the problem with autovacuum vacuuming > the same table over and over and being unable to remove enough dead > tuples due to something holding back the oldest xmin horizon. Why > can't we just fix that by remembering the value that > VacuumCutoffs.OldestXmin and only coming back to that table once > that's moved forward some amount? Users expect the tables to be auto vacuumed when: *dead_tuples > vac_base_thresh + vac_scale_factor * reltuples* If we depend on xid moving forward to do autovacuum, I think there are chances some bloated tables won't be vacuumed? > > David -- Regards Junwang Zhao