>> Things worth experimenting with (these are all untested, so please
>> report any successes):
>> 1) Try reformatting with a cluster size of 8Kb (the pg page size), if
>> you can.
>> 2) Disable the last access time (like noatime on linux). "fsutil
>> behavior set disablelastaccess 1"
>> 3) Disable 8.3 filenames "fsutil behavior set disable8dot3 1"
>>
>> 2 and 3 may require a reboot.
>>
>> (2 and 3 can be done on earlier windows through registry
>settings only,
>> in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem)
>
>I've repeated the test under 2 and 3 - no noticeable difference. With
>disablelastaccess I got about 10% - 15% better results, but it is not
>too significant.
Actually, that's enough to care about in a real world deployment.
>Finally I tried
>
>fsync = false
>
>and got 580-620 tps. So, the short summary:
>
>WinXP fsync = true 20-28 tps
>WinXP fsync = false 600 tps
>Linux 800 tps
This Linux figure is really compared to the WinXP fsync=false, since you
have write cacheing on. The interesting one to compare with is the other
one you did:
Linux w/o write cache 80-90 tps
Which is still faster than windows, but not as much faster.
>The general question is - does PostgreSQL really need fsync? I
>suppose it
>is a question for design, not platform-specific one. It sounds
>like only
>one scenario, when fsync is useful, is to interprocess
>communication via
>open file. But PostgreSQL utilize IPC for this, so does fsync is really
>required?
No, fsync is used to make sure your data is committed to disk once you
commit a transaction. IPC is handled through shared memory and named
pipes.
//Magnus