On Thu, Jan 19, 2023 at 5:51 PM Andres Freund <and...@anarazel.de> wrote: > I don't agree. But mainly my issue is that the devil you know (how this has > worked for a while) is preferrable to introducing an unknown quantity (your > patch that hasn't yet seen real world exposure).
Yeah, this is a major reason why I'm very leery about changes in this area. A lot of autovacuum behavior is emergent, in the sense that it wasn't directly intended by whoever wrote the code. It's just a consequence of other decisions that probably seemed very reasonable at the time they were made but turned out to have surprising and unpleasant consequences. In this particular case, I think that there is a large risk that postponing auto-cancellation will make things significantly worse, possibly drastically worse, for a certain class of users - specifically, those whose vacuums often get auto-cancelled. I think that it's actually pretty common for people to have workloads where something pretty close to all of the autovacuums get auto-cancelled on certain tables, and those people are always hard up against autovacuum_freeze_max_age because they *have* to hit that in order to get any vacuuming done on the affected tables. If the default threshold for auto-cancellation goes up, those people will be vacuuming even less often than they are now. That's why I really liked your idea of decoupling auto-cancellation from XID age. Such an approach can still avoid disabling auto-cancellation just because autovacuum_freeze_max_age has been hit, but it can also disable it much earlier when it detects that doing so is necessary to make progress. -- Robert Haas EDB: http://www.enterprisedb.com
