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