[EMAIL PROTECTED] wrote: > > I've made a test run that compares fsync and fdatasync: The performance > > was identical: > > - with fdatasync: > > > > http://khack.osdl.org/stp/290607/ > > > > - with fsync: > > http://khack.osdl.org/stp/290483/ > > > > I don't understand why. Mark - is there a battery backed write cache in > > the raid controller, or something similar that might skew the results? > > The test generates quite a lot of wal traffic - around 1.5 MB/sec. > > Perhaps the writes are so large that the added overhead of syncing the > > inode is not noticable? > > Is the pg_xlog directory on a seperate drive? > > > > Btw, it's possible to request such tests through the web-interface, see > > http://www.osdl.org/lab_activities/kernel_testing/stp/script_param.html > > We have 2 Adaptec 2200s controllers, without the battery backed add-on, > connected to four 10-disk arrays in those systems. I can't think of > anything off hand that would skew the results. > > The pg_xlog directory is not on a separate drive. I haven't found the > best way to lay out of the drives on those systems yet, so I just have > everything on a 28 drive lvm2 volume.
We don't actually extend the WAL file during writes (preallocated), and the access/modification timestamp is only in seconds, so I wonder of the OS only updates the inode once a second. What else would change in the inode more frequently than once a second? -- 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
