So when I suggested on linux-kernel that vacuumcould benefit from some way to
prioritize i/o resourcse, someone suggested vacuum could just throttle its own
disk accesses.
While I think they their conception of vacuum is still broken and the
throttling methods they described are the wrong direction, on further thought
I think they actually have the right idea.
pg_autovacuum knows at what rate free space has been accumulating. It knows
how large the fsm available is. It can therefore calculate exactly how much
time it has available to complete the next vacuum run before the fsm runs out
(assuming the free space continues accumulating at a constant rate).
If it passed that information on to vacuum then vacuum could throttle its own
disk accesses by, say, reading 64k at a time then sleeping for a fraction of a
second. The time spent sleeping would be calculated to have the vacuum take
the required total time.
This would produce a more even and less resource hogging duty cycle where
vacuum would be continuously running at low levels, rather than a duty cycle
where it doesn't run at all until it's needed, but then floods the disk
controllers with continuous sequential reads.
(There are a few details of course. You would need to leave a safety margin in
case free space accumulation speeds up. And accounting for the actual time
spent doing the vacuum would make calculating the sleep time tricky. But they
seem fairly tractable problems.)
Personally I think i/o priorities give much better leverage. It would let
vacuum run as fast as the disk subsystems can handle during idle times, and
then fade away as soon as any heavy transaction load appears. But the flip
side is that with i/o prioritization vacuum might not actually finish in time.
--
greg