Re: New GUC autovacuum_max_threshold ?

From: "Imseih (AWS), Sami" <simseih(at)amazon(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: 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>, Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com>, "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: 2024-05-08 17:30:44
Message-ID: 0A799687-DE0A-4BFC-8900-E1D57EB6C211@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> This is about how I feel, too. In any case, I +1'd a higher default
> because I think we need to be pretty conservative with these changes, at
> least until we have a better prioritization strategy. While folks may opt
> to set this value super low, I think that's more likely to lead to some
> interesting secondary effects. If the default is high, hopefully these
> secondary effects will be minimized or avoided.

There is also an alternative of making this GUC -1 by default, which
means it has not effect and any value larger will be used in the threshold
calculation of autovacuunm. A user will have to be careful not to set it too low,
but that is going to be a concern either way.

This idea maybe worth considering as it does not change the default
behavior of the autovac threshold calculation, and if a user has cases in
which they have many tables with a few billion tuples that they wish to
see autovacuumed more often, they now have a GUC to make
that possible and potentially avoid per-table threshold configuration.

Also, I think coming up with a good default will be challenging,
and perhaps this idea is a good middle ground.

Regards,

Sami

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2024-05-08 18:00:10 Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
Previous Message Jonathan S. Katz 2024-05-08 16:17:13 Re: 2024-05-09 release announcement draft