> > I have only one explanation: it reduces number of transactions ready
> > to commit (because of the same FK writers will wait till first one
> > committed - ie log fsynced) and WAL commit performance 
> > greatly depends on how many commits were done by single log fsync.
> > 7.0.3+nofsync commit performance doesn't depend on this factor.
> 
> Sure, but that's not exactly a fair comparison is it?  7.0.3+nofsync
> should be compared against 7.1+nofsync.  I put the pg_fsync routine
> back in a little while ago, so nofsync should work again.

But I tested old 7.1 (fsync) version -:)

And we always will have to enable fsync when comparing our
performance with other DBes.

> It occurs to me though that disabling fsync should probably 
> also reduce the WAL commit delay to zero, no?  What is the default

I think so.

> commit delay now?

As before 5 * 10^(-6) sec - pretty the same as sleep(0) -:)
Seems CommitDelay is not very useful parameter now - XLogFlush
logic and fsync time add some delay.

Vadim

Reply via email to