I would also suggest in addition to the other folks comments that you benchmark the 4 disks in RAID 10 in addition to RAID 5. RAID 5 typicaly has poor write performance because it must read the stripe, modify, calculate new parity and write, and if you are doing alot of inserts, you may find that RAID 10 performs better, particularly with large amounts of random writes (I actualy have benchmarking information for the 3ware escalade 9500S series RAID cards that I acquired from AMCC yestarday that shows these numbers to be true - of course each controler will vary with milleage (RAID 10: 91.4MBwrite/sec 256.2 IO/sec write, RAID 5: 75.4MBwrite/sec, 107.2 IO/sec write for a 4 Drive array)). Splitting WAL and Table data is an excellent way to speed up Pgsql, we do this and it is indeed very effective. Alex Turner NetEconomist On Mon, 10 Jan 2005 17:33:51 -0600, Guy Rouillier <guyr@xxxxxxxxxxx> wrote: > We are soon to be doing performance testing. Our testing environment > contains 4 SCSI disks in a RAID5 configuration, while our production > environment will have 6 SCSI disks, which I'm suggesting we allocate as > 4 in RAID5 for data and 2 in RAID1 for WAL. > > Because we don't have separate disks for WAL in our test environment, > I'd like to minimize the effect of WAL. I've read the sections in both > the tuning guide and the base documentation, and I'm still a little > unclear about fsync and wal_sync_method. If I set fsync FALSE, does > this disable WAL entirely? > > -- > Guy Rouillier > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
