Horton
Menu

Re: New GUC autovacuum_max_threshold ?

Nathan Bossart <nathandbossart@gmail.com>

View thread
From: Nathan Bossart <nathandbossart@gmail.com>
To: Sami Imseih <samimseih@gmail.com>
Cc: Frédéric Yhuel <frederic.yhuel@dalibo.com>, Robert Treat <rob@xzilla.net>, wenhui qiu <qiuwenhuifx@gmail.com>, Robert Haas <robertmhaas@gmail.com>, "Imseih (AWS), Sami" <simseih@amazon.com>, David Rowley <dgrowleyml@gmail.com>, Joe Conway <mail@joeconway.com>, Michael Banck <mbanck@gmx.net>, Laurenz Albe <laurenz.albe@cybertec.at>, Melanie Plageman <melanieplageman@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-01-14T17:45:42Z
Lists: pgsql-hackers 
On Tue, Jan 14, 2025 at 11:08:36AM -0600, Sami Imseih wrote:
> After staring at the documentation for a while, I am now
> wondering whether we are adequately describing the
> rationale for this GUC. The GUC documentation mentions that this is a
> 'cap on the value calculated with autovacuum_vacuum_threshold
> and autovacuum_vacuum_scale_factor,' which is acceptable;
> however, I think further elaboration is necessary in
> routine-vacuuming.html#AUTOVACUUM. This is because
> scale_factor and threshold are already well-known
> and widely understood parameters, and introducing
> a third one to the mix deserves a bit more of an
> explanation. What do you think?

I think it would be odd to explain the intent for one autovacuum parameter
while leaving the others unexplained.  IMHO it would be better to address
this for all such parameters in a follow-up patch.

-- 
nathan

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