On Tue, 5 Dec 2006, Craig A. James wrote:
I'm not familiar with the inner details of software RAID, but the only circumstance I can see where things would get corrupted is if the RAID driver writes a LOT of blocks to one disk of the array before synchronizing the others...
You're talking about whether the discs in the RAID are kept consistant. While it's helpful with that, too, that's not the main reason a the battery-backed cache is so helpful. When PostgreSQL writes to the WAL, it waits until that data has really been placed on the drive before it enters that update into the database. In a normal situation, that means that you have to pause until the disk has physically written the blocks out, and that puts a fairly low upper limit on write performance that's based on how fast your drives rotate. RAID 0, RAID 1, none of that will speed up the time it takes to complete a single synchronized WAL write.
When your controller has a battery-backed cache, it can immediately tell Postgres that the WAL write completed succesfully, while actually putting it on the disk later. On my systems, this results in simple writes going 2-4X as fast as they do without a cache. Should there be a PC failure, as long as power is restored before the battery runs out that transaction will be preserved.
What Alex is rightly pointing out is that a software RAID approach doesn't have this feature. In fact, in this area performance can be even worse under SW RAID than what you get from a single disk, because you may have to wait for multiple discs to spin to the correct position and write data out before you can consider the transaction complete.
-- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
