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
