RE: 7.0.3(nofsync) vs 7.1

From: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: 7.0.3(nofsync) vs 7.1
Date: 2000-12-09 01:39:38
Message-ID: 8F4C99C66D04D4118F580090272A7A234D31EB@sectorbase1.sectorbase.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2000-12-09 01:40:07 Japan pictures
Previous Message Tom Lane 2000-12-09 01:32:23 Re: 7.0.3(nofsync) vs 7.1