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@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
