Re: [BUG] Autovacuum not dynamically decreasing cost_limit and cost_delay

On 2021-Feb-08, Mead, Scott wrote:

> Hello,
> I recently looked at what it would take to make a running autovacuum
> pick-up a change to either cost_delay or cost_limit. Users frequently
> will have a conservative value set, and then wish to change it when
> autovacuum initiates a freeze on a relation. Most users end up
> finding out they are in ‘to prevent wraparound’ after it has happened,
> this means that if they want the vacuum to take advantage of more I/O,
> they need to stop and then restart the currently running vacuum (after
> reloading the GUCs).

Hello, I think this has been overlooked, right? I can't find a relevant
commit, but maybe I just didn't look hard enough. I have a feeling that
this is something that we should address. If you still have the cycles,
please consider posting an updated patch and creating a commitfest
entry.

Thanks

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Someone said that it is at least an order of magnitude more work to do
production software than a prototype. I think he is wrong by at least
an order of magnitude." (Brian Kernighan)