UPDATE: HAMMER and PostgreSQL Performance

[Matthew Dillon]

    Yah, lets see how it fares now that the random I/O read-ahead
    issue in cluster_read() has been fixed.  Just stick with fsync_mode=3
    (which is equivalent to what UFS does but requires even fewer
    discrete media writes).  The fsync modes have been completely revamped
    as of late 2.5 and mode 3 (REDO and wait for IO completion but no media
    sync) is now the default.

    I suspect random I/O crossing 64K data block boundaries will still
    have issues even with nohistory because on-media data blocks are not
    immediately reused.  An overwrite writes out a new datablock and
    changes the B-Tree record to point at it in order to guarantee that
    the old data block can be recovered by the crash recovery code.
    Reblocking the file will help there but it still presents a problem
    for a database which does a lot of writing.

						-Matt