On Fri, Jun 24, 2005 at 09:37:23AM -0400, Tom Lane wrote:
> ITAGAKI Takahiro <itagaki.takahiro@lab.ntt.co.jp> writes:
> > ... So I'll post the new results:
>
> > checkpoint_ | writeback |
> > segments | cache | open_sync | fsync=false | O_DIRECT only | fsync_direct | open_direct
> > ------------+-----------+-----------+---------------+---------------+---------------+--------------
> > [3] 3 | off | 38.2 tps | 138.8(+263.5%)| 38.6(+ 1.2%) | 38.5(+ 0.9%) | 38.5(+ 0.9%)
>
> Yeah, this is about what I was afraid of: if you're actually fsyncing
> then you get at best one commit per disk revolution, and the negotiation
> with the OS is down in the noise.
>
> At this point I'm inclined to reject the patch on the grounds that it
> adds complexity and portability issues, without actually buying any
> useful performance improvement. The write-cache-on numbers are not
> going to be interesting to any serious user :-(
Is there anyone with a battery-backed RAID controller that could run
these tests? I suspect that in that case the differences might be closer
to 1 or 2 rather than 3, which would make the patch much more valuable.
Josh, is this something that could be done in the performance lab?
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
