Re: New GUC autovacuum_max_threshold ?

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com>, Robert Treat <rob(at)xzilla(dot)net>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "Imseih (AWS), Sami" <simseih(at)amazon(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, Michael Banck <mbanck(at)gmx(dot)net>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: New GUC autovacuum_max_threshold ?
Date: 2025-01-14 17:45:42
Message-ID: Z4aixpJfyzkRfuJc@nathan
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2025-01-14 17:46:59 Re: CREATE TABLE NOT VALID for check and foreign key
Previous Message Robert Haas 2025-01-14 17:33:33 Re: Bypassing cursors in postgres_fdw to enable parallel plans