Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] fsync method checking

From: Manfred Spraul <manfred(at)colorfullife(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>,pgsql-performance(at)postgresql(dot)org,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] fsync method checking
Date: 2003-12-12 20:54:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-performance
Bruce Momjian wrote:

>	write                  0.000360
>	write & fsync          0.001391
>	write, close & fsync   0.001308
>	open o_fsync, write    0.000924
That's 1 milliseconds vs. 1.3 milliseconds. Neither value is realistic - 
I guess the hw cache on and the os doesn't issue cache flush commands. 
Realistic values are probably 5 ms vs 5.3 ms - 6%, not 30%. How large is 
the syscall latency with BSD/OS 4.3?

One advantage of a seperate write and fsync call is better performance 
for the writes that are triggered within AdvanceXLInsertBuffer: I'm not 
sure how often that's necessary, but it's a write while holding both the 
WALWriteLock and WALInsertLock. If every write contains an implicit 
sync, that call would be much more expensive than necessary.


In response to


pgsql-performance by date

Next:From: Mark KirkwoodDate: 2003-12-12 21:11:29
Subject: Re: Performance related to size of tables
Previous:From: nbarrazaDate: 2003-12-12 18:04:49
Subject: Performance related to size of tables

pgsql-hackers by date

Next:From: Matthew T. O'ConnorDate: 2003-12-12 20:59:04
Subject: Re: Resurrecting pg_upgrade
Previous:From: Tom LaneDate: 2003-12-12 20:42:56
Subject: Re: Resurrecting pg_upgrade

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group