On Thu, Mar 22, 2012 at 3:45 PM, Stephen Frost <sfr...@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
<<attachment: latency-10s.png>>
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
