> 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 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

Reply via email to