Re: rapid degradation after postmaster restart - Mailing list pgsql-performance

From Tom Lane
Subject Re: rapid degradation after postmaster restart
Date
Msg-id 21011.1079500660@sss.pgh.pa.us
Whole thread Raw
In response to Re: rapid degradation after postmaster restart  (Joe Conway <mail@joeconway.com>)
List 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 by date:

Previous
From: "Matthew T. O'Connor"
Date:
Subject: Re: rapid degradation after postmaster restart
Next
From: Joe Conway
Date:
Subject: Re: rapid degradation after postmaster restart