On Thu, Mar 22, 2012 at 3:45 PM, Stephen Frost <sfrost@snowman.net> wrote:
> Well, those numbers just aren't that exciting. :/
Agreed. There's clearly an effect, but on this test it's not very big.
> Then again, I'm a bit surprised that the latencies aren't worse, perhaps
> the previous improvements have made the checkpoint pain go away for the
> most part..
I think it's pretty obvious from the graph that the checkpoint pain
hasn't gone away; it's just that this particular approach doesn't do
anything to address the pain associated with this particular test.
> The graph is definitely interesting.. Would it be possible for you to
> produce a graph of latency over the time of the run? I'd be looking for
> spikes in latency near/around the 15m checkpoint marks and/or fsync
> times. If there isn't really one, then perhaps the checkpoint spreading
> is doing a sufficient job. Another option might be to intentionally
> tune the checkpoint spreading down to force it to try and finish the
> checkpoint faster and then see if the patches improve the latency in
> that situation. Perhaps, in whatever workloads there are which are
> better suited to faster checkpoints (there must be some, right?
> otherwise there wouldn't be a GUC for it..), these patches would help.
See attached. It looks a whole lot like the tps graph, if you look at
the tps graph upside with your 1/x glasses on.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
