Hi, On 2019-02-19 13:28:00 -0500, Robert Haas wrote: > 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. I agree that that's something worthwhile to do, but given that the proposal in this thread is *NOT* just about VACUUM, I don't see why it'd be useful to tie a general WAL rate limiting to rewriting cost limiting of vacuum. It seems better to write the WAL rate limiting logic with an eye towards structuring it in a way that'd potentially allow reusing some of the code for a better VACUUM cost limiting. I still don't *AT ALL* buy Stephen and Tomas' argument that it'd be confusing that when both VACUUM and WAL cost limiting are active, the lower limit takes effect. Greetings, Andres Freund
