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

Re: [HACKERS] fsync method checking

From: Manfred Spraul <manfred(at)colorfullife(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: markw(at)osdl(dot)org, josh(at)agliodbs(dot)com, Q(at)ping(dot)be,pgman(at)candle(dot)pha(dot)pa(dot)us, markir(at)paradise(dot)net(dot)nz,pgsql-performance(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] fsync method checking
Date: 2004-03-25 06:21:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-performance
Tom Lane wrote:

>markw(at)osdl(dot)org writes:
>>I could certainly do some testing if you want to see how DBT-2 does.
>>Just tell me what to do. ;)
>Just do some runs that are identical except for the wal_sync_method
>setting.  Note that this should not have any impact on SELECT
>performance, only insert/update/delete performance.
I've made a test run that compares fsync and fdatasync: The performance 
was identical:
- with fdatasync:

- with fsync:

I don't understand why. Mark - is there a battery backed write cache in 
the raid controller, or something similar that might skew the results? 
The test generates quite a lot of wal traffic - around 1.5 MB/sec. 
Perhaps the writes are so large that the added overhead of syncing the 
inode is not noticable?
Is the pg_xlog directory on a seperate drive?

Btw, it's possible to request such tests through the web-interface, see


In response to


pgsql-performance by date

Next:From: markwDate: 2004-03-25 17:16:40
Subject: Re: [HACKERS] fsync method checking
Previous:From: scott.marloweDate: 2004-03-24 18:13:55
Subject: Re: slow vacuum performance

pgsql-hackers by date

Next:From: David FetterDate: 2004-03-25 06:44:56
Subject: HEAD compile troubles
Previous:From: Dustin SallingsDate: 2004-03-25 05:25:30
Subject: Re: subversion vs cvs (Was: Re: linked list rewrite)

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