Re: New GUC autovacuum_max_threshold ?
От | Imseih (AWS), Sami |
---|---|
Тема | Re: New GUC autovacuum_max_threshold ? |
Дата | |
Msg-id | 0A799687-DE0A-4BFC-8900-E1D57EB6C211@amazon.com обсуждение исходный текст |
Ответ на | Re: New GUC autovacuum_max_threshold ? (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: New GUC autovacuum_max_threshold ?
|
Список | 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 по дате отправления: