Re: Introduce some randomness to autovacuum
От | Junwang Zhao |
---|---|
Тема | Re: Introduce some randomness to autovacuum |
Дата | |
Msg-id | CAEG8a3KAc5qot2iqtGMQRL11q29oj0HCDQH6_DM528uzpR3Z7A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Introduce some randomness to autovacuum (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: Introduce some randomness to autovacuum
|
Список | 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
В списке pgsql-hackers по дате отправления: