Re: rapid degradation after postmaster restart
От | Tom Lane |
---|---|
Тема | Re: rapid degradation after postmaster restart |
Дата | |
Msg-id | 21011.1079500660@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: rapid degradation after postmaster restart (Joe Conway <mail@joeconway.com>) |
Список | pgsql-performance |
Joe Conway <mail@joeconway.com> writes: > I have tested Tom's original patch now. The good news -- it works great > in terms of reducing the load imposed by vacuum -- almost to the level > of being unnoticeable. The bad news -- in a simulation test which loads > an hour's worth of data, even with delay set to 1 ms, vacuum of the > large table exceeds two hours (vs 12-14 minutes with delay = 0). Since > that hourly load is expected 7 x 24, this obviously isn't going to work. Turns the dial down a bit too far then ... > The problem with Jan's more complex version of the patch (at least the > one I found - perhaps not the right one) is it includes a bunch of other > experimental stuff that I'd not want to mess with at the moment. Would > changing the input units (for the original patch) from milli-secs to > micro-secs be a bad idea? Unlikely to be helpful; on most kernels the minimum sleep delay is 1 or 10 msec, so asking for a few microsec is the same as asking for some millisec. I think what you need is a knob of the form "sleep N msec after each M pages of I/O". I'm almost certain that Jan posted such a patch somewhere between my original and the version you refer to above. regards, tom lane
В списке pgsql-performance по дате отправления: