MIME-Version: 1.0
References: <Zy-G7u43r1siVkQ6@nathan> <2ca7f9c7-5da9-46cb-9072-39b71bfab948@dalibo.com>
 <CAGjGUAKSvvQA583hk-62HyBRhPvowNbhv5+QiRt+znWMA+5OLg@mail.gmail.com>
 <Z32xZZwOi5pXZjYU@nathan> <93f3dab5-caa4-4213-9be0-855d5aaa19bf@dalibo.com>
 <Z37ZlVqUzSapV3ZD@nathan> <CABV9wwNxNTEgq0n5DJVDD+mgMbqBJv1-W6R3Dfry4a9C9=z=Uw@mail.gmail.com>
 <Z4AQJYdOsvVHNIbt@nathan> <Z4V1sDjqJ1CnqScY@nathan> <CAA5RZ0tAqjtJz+2=S1LvDUJfrpGa73nmLccwvr_R1r8CC4HmaA@mail.gmail.com>
 <Z4XHQR6_AVKiyFjG@nathan>
In-Reply-To: <Z4XHQR6_AVKiyFjG@nathan>
From: Sami Imseih <samimseih@gmail.com>
Date: Tue, 14 Jan 2025 11:08:36 -0600
Message-ID: <CAA5RZ0sgq90BvbQry4bRcFNpz6S+A08iTguk=N-dcBW51Z3CeA@mail.gmail.com>
Subject: Re: New GUC autovacuum_max_threshold ?
To: Nathan Bossart <nathandbossart@gmail.com>, 
	=?UTF-8?B?RnLDqWTDqXJpYyBZaHVlbA==?= <frederic.yhuel@dalibo.com>
Cc: 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>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAA5RZ0sgq90BvbQry4bRcFNpz6S%2BA08iTguk%3DN-dcBW51Z3CeA%40mail.gmail.com>
Precedence: bulk

> Good call.  Here is an updated patch.

thanks for the update!

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?

Based on my understanding of the discussion, the purpose
of the GUC is to prevent large tables from experiencing
extended periods without an autovacuum, particularly
because scale_factor triggers vacuuming less
frequently as the table grows.

Currently, users can handle such cases by disabling (or lowering)
autovacuum_vacuum_scale_factor and setting an appropriate
autovacuum_vacuum_threshold; Therefore, this GUC becomes
a more convenient and predictable way to ensure autovacuum
triggers on a large table. Is this correct?

Regards,

Sami