AFAIK, the reason why seperating pg_xlog from the base files provides so much performance is because the latency on pg_xlog is critical: a transaction can't commit until all of it's log data is written to disk via fsync, and if you're trying to fsync frequently on the same drive as the data tables are on, you'll have a big problem with the activity on the data drives competing with trying to fsync pg_xlog rapidly. But if you have a raid array with a battery-backed controller, this shouldn't be anywhere near as big an issue. The fsync on the log will return very quickly thanks to the cache, and the controller is then free to batch up writes to pg_xlog. Or at least that's the theory. Has anyone actually done any testing on this? Specifically, I'm wondering if the benefit of adding 2 more drives to a RAID10 outweighs whatever penalties there are to having pg_xlog on that RAID10 with all the rest of the data. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@xxxxxxxxxxxxx Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
