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.


1st run:

real    11m27.107s
user    0m26.570s
sys     0m1.150s

2nd run:

real    6m5.712s
user    0m26.700s
sys     0m1.700s


1st run:

real    15m8.127s
user    0m26.710s
sys     0m0.990s

2nd run:

real    15m8.396s
user    0m26.990s
sys     0m1.870s


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

Reply via email to