A _very_ valid point which I omitted simply because it once again points to 24 spindles equating to a faster array than 12. The problem, as you so easily summarize, is the fact that once you put any decent RAID controller into this, you've essentially added a magic black box that does "better" things for the underlying storage which you simply cannot compute with these sorts of numbers.
ASSUMING that your raid controller is a good one (and Perc is), you should end up with a scenario that simply boils down to "more spindles will be faster." In theory. In practice, I find that theory holds up only erratically. ----- "Greg Smith" <g...@2ndquadrant.com> wrote: > Scott Whitney wrote: > > On the 10k vs 15k rpm disks, there's a _lot_ to be said about that. I don't > > want to start a flame war here, > > but 15k versus 10k rpm hard drives does NOT equivocate to a 50% increase in > > read/write times, to say > > the VERY least. > > > > Your characterization is correct were there only the drives involved > here, so no flames on your raw data. > > Once you've introduced a battery-backed write cache into the mix, this > whole area becomes impossible to compute that way though, and it was > that context I was commenting from at least. Those are good at turning > random I/O into something more like sequential, as well as reducing the > number of times you pay for rotational latency in several common > database operations. The effective impact is to significantly narrow > the difference between drives where the seek and rotation time are the > main differences in a database context--even though the worst-case IOPS > doesn't really change. IOPS is an interesting number to compute, but > real-world database performance isn't linearly correlated with it. > Maybe if your workload consists mainly of random, uncached index scans > system performance will scale just like IOPS, but that's pretty uncommon. > > [Rant about making sure not to drink the storage vendor IOPS Kool-Aid > deleted] > > -- > Greg Smith 2ndQuadrant US Baltimore, MD > PostgreSQL Training, Services and Support > g...@2ndquadrant.com www.2ndQuadrant.us > >