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
