Managing autovacuum freezing

We're observing I/O contention (including long COMMIT times) that are coinciding with anti-wraparound autovacuums of a particularly busy table. This table sees roughly 100K updates per hour. There are a handful (~500) inserts per hour and rarely any deletes at all. Very update-heavy. The table has just around 5Million rows, so it's not really very big at all, but there are around 10Million dead rows as well, so there's bloat involved.

Autovacuum has been disabled on this table for a couple years now (before my time here) and nightly VACUUM ANALYZE jobs are run via crontab. However every 2-3 days we'll see the anti-wraparound autovacuum run for this table and really tank I/O.

My understanding is that these manual VACUUM ANALYZE jobs are not freezing rows that regular autovacuuming would otherwise be doing, which leads up to the big anti-wraparound job.

We haven't changed any of the vacuum/autovacuum GUC parameters (although yesterday I noticed our cookbook is using the old autovacuum_vacuum_cost_delay=20ms default from pre-PG12). I'm assuming we'll need to do some table-specific tuning for this very active table if we were to re-enable autovacuum on it. I'm assuming we'll want to do more frequent (and less intensive) autovacuums throughout the day.

My concern first is whether or not autovacuum would be able to keep up throughout the day, no matter how well it is tuned. Not sure how I can gauge that before pulling the trigger though.

If we exhaust all tuning options, we could look at making those nightly VACUUM ANALYZE jobs into VACUUM FREEZE ANALYZE jobs so at least we take the I/O hit during off-peak hours.

Anyway, I'm very interested in what others on the list may have experienced in this area and what solutions you came up with. Thanks!

Don.
--