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

From Joe Conway
Subject Re: rapid degradation after postmaster restart
Date
Msg-id 4057D8BD.4080902@joeconway.com
Whole thread Raw
In response to Re: rapid degradation after postmaster restart  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: rapid degradation after postmaster restart  ("Matthew T. O'Connor" <matthew@zeut.net>)
Re: rapid degradation after postmaster restart  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: rapid degradation after postmaster restart  ("Arthur Ward" <award@dominionsciences.com>)
List pgsql-performance
Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
>
>>Any idea where I can get my hands on the latest version. I found the
>>original post from Tom, but I thought there was a later version with
>>both number of pages and time to sleep as knobs.
>
> That was as far as I got.  I think Jan posted a more complex version
> that would still be reasonable to apply to 7.4.

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.

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? If so, I guess I'll get to extracting what I
need from Jan's patch.

Thanks,

Joe


pgsql-performance by date:

Previous
From: "Aaron Werman"
Date:
Subject: Re: atrocious update performance
Next
From: "Matthew T. O'Connor"
Date:
Subject: Re: rapid degradation after postmaster restart