On 9/18/25 01:22, Andres Freund wrote: > Hi, > > On 2025-09-17 13:25:11 +0200, Tomas Vondra wrote: >> I believe the reason why parallelism is disabled in autovacuum is that >> we want autovacuum to be a background process, with minimal disruption >> to user workload. It probably wouldn't be that hard to allow autovacuum >> to do parallel stuff, but it feels similar to adding autovacuum workers. >> That's rarely the solution, without increasing the cost limit. > > I continue to find this argument extremely unconvincing. It's very common for > autovacuum to be continuously be busy with the one large table that has a > bunch of indexes. Vacuuming that one table is what prevents the freeze horizon > to move forward / prevents getting out of anti-wraparound territory in time. >
OK. I'm not claiming the argument is correct, I mostly asking if this was the argument for not allowing parallelism in autovacuum. I don't doubt an autovacuum worker can get "stuck" on a huge table, holding back the freeze horizon. But does it happen even with an increased cost limit? And is the bottleneck I/O or CPU? If it's vacuum_cost_limit, then the right "fix" is increasing the limit. Just adding workers improves nothing. If it's waiting on I/O, then adding workers is not going to help much. With CPU bottleneck it might, though. Does that match the cases you saw? regards -- Tomas Vondra
