Hi,
On 2025-09-18 02:00:50 +0200, Tomas Vondra wrote:
> 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?
Cost limit can definitely be sometimes be the issue and indeed in that case
increasing parallelism is the wrong answer. But I've repeatedly seen autovac
being bottlenecked by CPU and/or I/O.
Greetings,
Andres Freund
