Re: Introduce some randomness to autovacuum

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Junwang Zhao <zhjwpku(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Introduce some randomness to autovacuum
Date: 2025-05-01 00:11:54
Message-ID: CAApHDvrdxSwUt3sqhWMNnb_QwaX1A1TCuFWzCvirqKZo9aK_QQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 1 May 2025 at 03:29, Nathan Bossart <nathandbossart(at)gmail(dot)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?

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-05-01 00:18:01 Re: Performance issues with v18 SQL-language-function changes
Previous Message Michael Paquier 2025-04-30 22:56:02 Re: Prevent an error on attaching/creating a DSM/DSA from an interrupt handler.