Robert Haas wrote:
> Now, in the case where you are setting an overall limit, there is at
> least an argument to be made that you can determine the overall rate
> of autovacuum-induced I/O activity that the system can tolerate, and
> set your limits to stay within that budget, and then let the system
> decide how to divide that I/O up between workers. But if you're
> overriding a per-table limit, I don't really see how that holds any
> water. The system I/O budget doesn't go up just because one
> particular table is being vacuumed rather than any other. The only
> plausible use case for setting a per-table rate that I can see is when
> you actually want the system to use that exact rate for that
> particular table.
Yeah, this makes sense to me too -- at least as long as you only have
one such table. But if you happen to have more than one, and due to
some bad luck they happen to be vacuumed concurrently, they will eat a
larger share of your I/O bandwidth budget than you anticipated, which
you might not like.
Thus what I am saying is that those should be scaled down too to avoid
peaks. Now, my proposal above mentioned subtracting the speed of tables
under the limit, from the speed of those above the limit; maybe we can
just rip that part out. Then we end up with the behavior you want, that
is to have the fast table vacuum as fast as it is configured when it's
the only fast table being vacuumed; and also with what I say, which is
that if you have two of them, the two balance the I/O consumption (but
only among themselves, not with the slow ones.)
Since figuring out this subtraction is the only thing missing from the
patch I posted, ISTM we could have something committable with very
little extra effort if we agree on this.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
