Tom Lane wrote:
>>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
- 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: markw||Date: 2004-03-25 17:16:40|
|Subject: Re: [HACKERS] fsync method checking|
|Previous:||From: scott.marlowe||Date: 2004-03-24 18:13:55|
|Subject: Re: slow vacuum performance|
pgsql-hackers by date
|Next:||From: David Fetter||Date: 2004-03-25 06:44:56|
|Subject: HEAD compile troubles|
|Previous:||From: Dustin Sallings||Date: 2004-03-25 05:25:30|
|Subject: Re: subversion vs cvs (Was: Re: linked list rewrite) |