Re: New GUC autovacuum_max_threshold ? - Mailing list pgsql-hackers

From Imseih (AWS), Sami
Subject Re: New GUC autovacuum_max_threshold ?
Date
Msg-id 0A799687-DE0A-4BFC-8900-E1D57EB6C211@amazon.com
Whole thread Raw
In response to Re: New GUC autovacuum_max_threshold ?  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: New GUC autovacuum_max_threshold ?
List 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 




pgsql-hackers by date:

Previous
From: "Jonathan S. Katz"
Date:
Subject: Re: 2024-05-09 release announcement draft
Next
From: Alexander Korotkov
Date:
Subject: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands