Hi, > The current range 1..INT_MAX/1000 is indeed pretty wide, but I think > it's hard, or even impossible, to conclude that no one would ever > want more than X. Could the documentation be improved perhaps?
Yes, 0001 does that. The docs now say that a large value delays all autovacuum work in a database, wraparound vacuums included, and that raising it only helps clusters with very many databases. It stands on its own. > I’ve heard through various channels that `autovacuum_naptime` > was mistakenly set to 23 hours, resulting in an XID wraparound incident. We also had customer runs into that issue before. In general, I agree with wenhui that 3600 is fine, because I can't find a downside. The only thing a larger value changes is how often a worker starts in each database. Starting a worker costs about 13ms of CPU here, with empty databases or with 2000 tables in each. So at naptime 1h, all the worker starts in a cluster with 1000 databases cost about 0.4% of one core, and with 10000 databases about 4%. That is everything a larger value could save. My understanding is that a cluster that large runs on a big machine, so saving that much CPU means nothing in practice. 0002 lowers the max to 3600. Two notes on it. contrib/test_decoding/logical.conf sets 1d to keep autovacuum quiet, so I changed it to autovacuum = off An old config above the new max stops the server from starting, so 0002 is for master only. Thanks, Shihao
v1-0002-Lower-the-maximum-of-autovacuum_naptime-to-one-ho.patch
Description: Binary data
v1-0001-doc-Explain-what-a-large-autovacuum_naptime-does.patch
Description: Binary data
