Re: [PERFORM] fsync method checking - Mailing list pgsql-hackers

From Manfred Spraul
Subject Re: [PERFORM] fsync method checking
Date
Msg-id 40627A6F.9010202@colorfullife.com
Whole thread Raw
In response to Re: [PERFORM] fsync method checking  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PERFORM] fsync method checking
List pgsql-hackers
Tom Lane wrote:

>markw@osdl.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:

http://khack.osdl.org/stp/290607/

- with fsync:
http://khack.osdl.org/stp/290483/

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
http://www.osdl.org/lab_activities/kernel_testing/stp/script_param.html

--
    Manfred


pgsql-hackers by date:

Previous
From: Dustin Sallings
Date:
Subject: Re: subversion vs cvs (Was: Re: linked list rewrite)
Next
From: David Fetter
Date:
Subject: HEAD compile troubles