>> 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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
