Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I have been poking around with our fsync default options to see if I can > > improve them. One issue is that we never default to O_SYNC, but default > > to O_DSYNC if it exists, which seems strange. > > As I recall, that was based on testing on some different platforms. > It's not particularly "strange": O_SYNC implies writing at least two > places on the disk (file and inode). O_DSYNC or fdatasync should > theoretically be the fastest alternatives, O_SYNC and fsync the worst.
But why perfer O_DSYNC over fdatasync if you don't prefer O_SYNC over fsync? > > > Compare fsync before and after write's close: > > write, fsync, close 0.000707 > > write, close, fsync 0.000808 > > What does that mean? You can't fsync a closed file. You reopen and fsync. > > This shows terrible O_SYNC performance for 2 8k writes, but is faster > > for a single 8k write. Strange. > > I'm not sure I believe these numbers at all... my experience is that > getting trustworthy disk I/O numbers is *not* easy. These numbers were reproducable on all the platforms I tested. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(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
