From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
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:58:36 |
Message-ID: | 9663.976327116@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> writes:
> And we always will have to enable fsync when comparing our
> performance with other DBes.
Of course, but when people say "it's slower than 7.0.3+nofsync"
I think that turning off fsync makes a fairer comparison there.
>> 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.
There was a thread recently about smarter ways to handle shared fsync
of the log --- IIRC, we talked about self-tuning commit delay, releasing
waiting processes as soon as someone else had fsync'd, etc. Looks like
none of those ideas are in the code now. Did you not like any of those
ideas, or just no time to work on it yet?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Snow | 2000-12-09 01:58:41 | Re: OK, does anyone have any better ideas? |
Previous Message | Bruce Momjian | 2000-12-09 01:40:07 | Japan pictures |