Hmmm.... it [font="Arial Black"]really [/font]goes against my inner data-troll but, instead of spending who knows how much on fixing and regression testing the crap code that's causing all of those writes, it might just be worth the hardware investment.

Part of the reason it goes against my inner data-troll is because I don't want to set the precedent that it's OK to write crap code just because the SSDs might be able to handle it especially since there's normally a fair amount of CPU time that goes along with the writes. CPUs cost a whole lot more than disks of any type if you consider licensing, etc, etc.

An example of what I'm talking about (and I realize this has nothing to do with writes) is that one of our applications was setup to read a 4.7 million row table using a DISTINCT... to return a 51 row menu.... every time the menu was used... and it's used about 1,000 times per hour. It was using more than 4 CPU hours per 8 hour day and well over a TB of reads (just for this one menu!!!). The fix for that was pretty easy and we got the total CPU time down to seconds and the number of reads down to a sliver.

My point is that with an SSD, people would be tempted to let something like that go but I suspect the CPU time used would still be there. It's also one of those pieces of code that was poorly written because the table was much smaller when this all started and the duration was satisfactory. Now, with SSDs, folks have an additional justification to pump out rather thoughtless code and because of the reduction in the duration caused by the increased I/O speed, an unwary DBA might not pick up on how much CPU time is being used for such a terribly simple thing.

As with any growing system, we have a whole lot of other code in the same boat and it's just going to get worse for the CPUs.

The writes are another thing caused simply by a lack of understanding of how to update data from one system to another. It involves mostly 2 large tables and I'm surprised it hasn't "cut a path" in the proverbial carpet of the current disk system. I think the related processes would be pretty tough on the life expectancy of the spots hit on an SSD for that. Even if I had SSDs that lasted a for a hundred years, the related unnecessarily high CPU usage is high enough to warrent fixing.

Heh... of course, the way around the problem of keeping developers from writing additional CPU performance challenged code is to continue to do what I've always done. Use the worst server available for the Dev box. No SSDs there! 😛