"Greg Smith" <[EMAIL PROTECTED]> writes: > On Fri, 15 Jun 2007, Gregory Stark wrote: > >> If I understand it right Greg Smith's concern is that in a busier system >> where even *with* the load distributed checkpoint the i/o bandwidth demand >> during t he checkpoint was *still* being pushed over 100% then spreading out >> the load would only exacerbate the problem by extending the outage. > > Thank you for that very concise summary; that's exactly what I've run into. > DBT2 creates a heavy write load, but it's not testing a real burst behavior > where something is writing as fast as it's possible to.
Ah, thanks, that's precisely the distinction that I was missing. It's funny, something that was so counter-intuitive initially has become so ingrained in my thinking that I didn't even notice I was assuming it any more. DBT2 has "think times" which it uses to limit the flow of transactions. This is critical to ensuring that you're forced to increase the scale of the database if you want to report larger transaction rates which of course is what everyone wants to brag about. Essentially this is what makes it an OLTP benchmark. You're measuring how well you can keep up with a flow of transactions which arrive at a fixed speed independent of the database. But what you're concerned about is not OLTP performance at all. It's a kind of DSS system -- perhaps there's another TLA that's more precise. But the point is you're concerned with total throughput and not response time. You don't have a fixed rate imposed by outside circumstances with which you have to keep up all the time. You just want to be have the highest throughput overall. The good news is that this should be pretty easy to test though. The main competitor for DBT2 is BenchmarkSQL whose main deficiency is precisely the lack of support for the think times. We can run BenchmarkSQL runs to see if the patch impacts performance when it's set to run as fast as possible with no think times. While in theory spreading out the writes could have a detrimental effect I think we should wait until we see actual numbers. I have a pretty strong suspicion that the effect would be pretty minimal. We're still doing the same amount of i/o total, just with a slightly less chance for the elevator algorithm to optimize the pattern. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq