Horton
Menu

Re: New GUC autovacuum_max_threshold ?

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Joe Conway <mail@joeconway.com>
Cc: Michael Banck <mbanck@gmx.net>, Laurenz Albe <laurenz.albe@cybertec.at>, Frédéric Yhuel <frederic.yhuel@dalibo.com>, Nathan Bossart <nathandbossart@gmail.com>, Melanie Plageman <melanieplageman@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, David Rowley <dgrowleyml@gmail.com>
Date: 2024-04-26T13:31:23Z
Lists: pgsql-hackers 
On Fri, Apr 26, 2024 at 9:22 AM Joe Conway <mail@joeconway.com> wrote:
> Although I don't think 500000 is necessarily too small. In my view,
> having autovac run very quickly, even if more frequently, provides an
> overall better user experience.

Can you elaborate on why you think that? I mean, to me, that's almost
equivalent to removing autovacuum_vacuum_scale_factor entirely,
because only for very small tables will that calculation produce a
value lower than 500k.

We might need to try to figure out some test cases here. My intuition
is that this is going to vacuum large tables insanely aggressively.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

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