I wrote: > [ worries about overflow with VacuumCostLimit approaching INT_MAX ]
Actually, now that I think a bit harder, that disquisition was silly. In fact, I'm inclined to argue that the already-committed patch is taking the wrong approach, and we should revert it in favor of a different idea. The reason is this: what we want to do is throttle VACUUM's I/O demand, and by "throttle" I mean "gradually reduce". There is nothing gradual about issuing a few million I/Os and then sleeping for many milliseconds; that'll just produce spikes and valleys in the I/O demand. Ideally, what we'd have it do is sleep for a very short interval after each I/O. But that's not too practical, both for code-structure reasons and because most platforms don't give us a way to so finely control the length of a sleep. Hence the design of sleeping for awhile after every so many I/Os. However, the current settings are predicated on the assumption that you can't get the kernel to give you a sleep of less than circa 10ms. That assumption is way outdated, I believe; poking around on systems I have here, the minimum delay time using pg_usleep(1) seems to be generally less than 100us, and frequently less than 10us, on anything released in the last decade. I propose therefore that instead of increasing vacuum_cost_limit, what we ought to be doing is reducing vacuum_cost_delay by a similar factor. And, to provide some daylight for people to reduce it even more, we ought to arrange for it to be specifiable in microseconds not milliseconds. There's no GUC_UNIT_US right now, but it's time. (Perhaps we should also look into using other delay APIs, such as nanosleep(2), where available.) I don't have any particular objection to kicking up the maximum value of vacuum_cost_limit by 10X or so, if anyone's hot to do that. But that's not where we ought to be focusing our concern. And there really is a good reason, not just nannyism, not to make that setting huge --- it's just the wrong thing to do, as compared to reducing vacuum_cost_delay. regards, tom lane