On Fri, Feb 15, 2019 at 1:42 PM Andres Freund <and...@anarazel.de> wrote: > I think it'd not be insane to add two things: > - WAL write rate limiting, independent of the vacuum stuff. It'd also be > used by lots of other bulk commands (CREATE INDEX, ALTER TABLE > rewrites, ...) > - Account for WAL writes in the current vacuum costing logic, by > accounting for it using a new cost parameter > > Then VACUUM would be throttled by the *minimum* of the two, which seems > to make plenty sense to me, given the usecases.
Or maybe we should just blow up the current vacuum cost delay stuff and replace it with something that is easier to tune. For example, we could just have one parameter that sets the maximum read rate in kB/s and another that sets the maximum dirty-page rate in kB/s. Whichever limit is tighter binds. If we also have the thing that is the topic of this thread, that's a third possible upper limit. I really don't see much point in doubling down on the current vacuum cost delay logic. The overall idea is good, but the specific way that you have to set the parameters is pretty inscrutable, and I think we should just fix it so that it can be, uh, scruted. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
