Re: [PERFORM] fsync method checking
От | Manfred Spraul |
---|---|
Тема | Re: [PERFORM] fsync method checking |
Дата | |
Msg-id | 40627A6F.9010202@colorfullife.com обсуждение исходный текст |
Ответ на | Re: [PERFORM] fsync method checking (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PERFORM] fsync method checking
|
Список | 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 по дате отправления: