Horton
Menu

Re: New GUC autovacuum_max_threshold ?

Vinícius Abrahão <vinnix.bsd@gmail.com>

View thread
From: Vinícius Abrahão <vinnix.bsd@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Frédéric Yhuel <frederic.yhuel@dalibo.com>, 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-08T21:32:58Z
Lists: pgsql-hackers 
On Wed, Jan 8, 2025 at 8:01 PM Nathan Bossart <nathandbossart@gmail.com>
wrote:

> On Wed, Jan 08, 2025 at 02:48:10PM +0100, Frédéric Yhuel wrote:
> > For what it's worth, although I would have preferred the sub-linear
> growth
> > thing, I'd much rather have this than nothing.
>
> +1, this is how I feel, too.  But I also don't want to add something that
> folks won't find useful.
>
> > And I have to admit that the proposed formulas were either too
> convoluted or
> > wrong.
> >
> > This very patch is more straightforward. Please let me know if I can help
> > and how.
>
> I read through the thread from the top, and it does seem like there is
> reasonably strong support for the hard cap.  Upon a closer review of the
> patch, I noticed that the relopt was defined such that you couldn't disable
> autovacuum_max_threshold on a per-table basis, so I fixed that in v4.
>
> --
> nathan
>


nathan,

Please also provide the tests on the new parameter you want to introduce.

Best,
vini

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