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.
