On Fri, 10 Oct 2003, Josh Berkus wrote: > Bruce, > > > Yes. If you were doing multiple WAL writes before transaction fsync, > > you would be fsyncing every write, rather than doing two writes and > > fsync'ing them both. I wonder if larger transactions would find > > open_sync slower? > > Want me to test? I've got an ide-based test machine here, and the TPCC > databases.
OK, I decided to do a quick dirty test of things that are big transactions in each mode my kernel supports. I did this: createdb dbname time pg_dump -O -h otherserver dbname|psql dbname then I would drop the db, edit postgresql.conf, and restart the server. open_sync was WAY faster at this than the other two methods. open_sync: 1st run: real 11m27.107s user 0m26.570s sys 0m1.150s 2nd run: real 6m5.712s user 0m26.700s sys 0m1.700s fsync: 1st run: real 15m8.127s user 0m26.710s sys 0m0.990s 2nd run: real 15m8.396s user 0m26.990s sys 0m1.870s fdatasync: 1st run: real 15m47.878s user 0m26.570s sys 0m1.480s 2nd run: real 15m9.402s user 0m27.000s sys 0m1.660s I did the first runs in order, then started over, i.e. opensync run1, fsync run1, fdatasync run1, opensync run2, etc... The machine I was restoring to was under no other load. The machine I was reading from had little or no load, but is a production server, so it's possible the load there could have had a small effect, but probably not this big of a one. The machine this is one is setup so that the data partition is on a drive with write cache enabled, but the pg_xlog and pg_clog directories are on a drive with write cache disabled. Same drive models as listed before in my previous test, Seagate generic 80gig IDE drives, model ST380023A. ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster