Re: checkpoint patches

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