Horton
Menu

Re: New GUC autovacuum_max_threshold ?

Michael Banck <mbanck@gmx.net>

View thread
From: Michael Banck <mbanck@gmx.net>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Robert Haas <robertmhaas@gmail.com>, Nathan Bossart <nathandbossart@gmail.com>, Melanie Plageman <melanieplageman@gmail.com>, Frédéric Yhuel <frederic.yhuel@dalibo.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, David Rowley <dgrowleyml@gmail.com>
Date: 2024-04-26T08:08:33Z
Lists: pgsql-hackers 
Hi,

On Fri, Apr 26, 2024 at 04:24:45AM +0200, Laurenz Albe wrote:
> On Thu, 2024-04-25 at 14:33 -0400, Robert Haas wrote:
> > Another reason, at least in existing releases, is that at some
> > point index vacuuming hits a wall because we run out of space for dead
> > tuples. We *most definitely* want to do index vacuuming before we get
> > to the point where we're going to have to do multiple cycles of index
> > vacuuming.
> 
> That is more convincing.  But do we need a GUC for that?  What about
> making a table eligible for autovacuum as soon as the number of dead
> tuples reaches 90% of what you can hold in "autovacuum_work_mem"?

Due to the improvements in v17, this would basically never trigger
accordings to my understanding, or at least only after an excessive
amount of bloat has been accumulated.


Michael

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Introduce autovacuum_vacuum_max_threshold.

  2. Consolidate docs for vacuum-related GUCs in new subsection