> >> 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
signature.asc
Description: This is a digitally signed message part.
