* Robert Haas (robertmhaas@gmail.com) wrote:
> TPS numbers:
>
> checkpoint-sync-pause-v1: 2594.448538, 2600.231666, 2580.041376
> master: 2466.399991, 2450.752843, 2291.613305
>
> 90th percentile latency:
>
> checkpoint-sync-pause-v1: 1487, 1488, 1481
> master: 1493, 1519, 1507
Well, those numbers just aren't that exciting. :/
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..
> The graph attached here is based on tps averaged over ten second
> intervals.
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.
Thanks,
Stephen
