On Thu, Aug 28, 2014 at 11:06 PM, Alvaro Herrera <
alvherre@2ndquadrant.com> wrote:
>
> 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.
I think to control I/O bandwidth, there should be a separate mechanism
(may be similar to what Simon proposed for WAL rate limiting) rather
than by changing user specified values internally where he might
specifically want that value to be used. This can give more predictable
results which user can control.