Gaetano,
> Now that the argument is already open, why postgres choose
> on linux fdatasync? I'm understanding from other posts that
> on this platform open_sync is better than fdatasync.
Not necessarily. For example, here's my test results, on Linux 2.6.7,
writing to a ReiserFS mount on a Software RAID 1 slave of 2 IDE disks, on an
Athalon 1600mhz single-processor machine. I ran the loop 10,000 times
instead of 1000 because tests with 1,000 varied too much.
Simple write timing:
write 0.088701
Compare fsync times on write() and non-write() descriptor:
(If the times are similar, fsync() can sync data written
on a different descriptor.)
write, fsync, close 3.593958
write, close, fsync 3.556978
Compare one o_sync write to two:
one 16k o_sync write 42.951595
two 8k o_sync writes 11.251389
Compare file sync methods with one 8k write:
(o_dsync unavailable)
open o_sync, write 6.807060
write, fdatasync 7.207879
write, fsync, 7.209087
Compare file sync methods with 2 8k writes:
(o_dsync unavailable)
open o_sync, write 13.120305
write, fdatasync 7.583871
write, fsync, 7.801748
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
