On Fri, 2006-06-09 at 14:41, Jim C. Nasby wrote: > 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. I tested it WAY back when 7.4 first came out on a machine with BBU, and it didn't seem to make any difference HOW I set up the hard drives, RAID-5, 1+0, 1 it was all about the same. With BBU the transactions per second varied very little. If I recall correctly, it was something like 600 or so tps with pgbench (scaling and num clients was around 20 I believe) It's been a while. In the end, that server ran with a pair of 18 Gig drives in a RAID-1 and was plenty fast for what we used it for. Due to corporate shenanigans it was still running pgsql 7.2.x at the time. ugh. I've not got access to a couple of Dell servers I might be able to test this on... After our security audit maybe.
