> >> Parallelism is not free, ever, and particularly not here, where it has
> >> the potential to yank the disk head around between five different
> >> files, seeking like crazy, instead of a nice sequential I/O pattern on
> >> each file in turn.
> >
> > Interesting point. Maybe what's going on here is that
> > autovac_balance_cost() is wrong to suppose that N workers can each have
> > 1/N of the I/O bandwidth that we'd consider okay for a single worker to
> > eat. Maybe extra seek costs mean we have to derate that curve by some
> > large factor. 1/(N^2), perhaps? I bet the nature of the disk subsystem
> > affects this a lot, though.
>
> ...and this would have the same effect. Let's not assume that the
> problem is that Josh doesn't know how to make autovacuum less
> aggressive, because I'm pretty sure that ain't the issue.
we may need reserved workers to work on system tables, at least.
Just as a protection in case all workers all locked hours walking 'log'
tables. In the meantime, the pg_type table can bloat a lot for ex.
It might be that limiting the number of workers in 'antiwraparound-mode' to
(max_workers - round(max_workers/3)) is enough.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation