Tom, > That analysis is far too simplistic, because only the WAL > write has to happen before the transaction can commit. The > table and index writes will normally happen at some later > point in the bgwriter, and with any luck there will only need > to be one write per page, not per tuple. That's good to know - makes sense. I suppose we might still thrash over a 1GB range in seeks if the BG writer starts running at full rate in the background, right? Or is there some write combining in the BG writer? > It is true that having WAL and data on the same spindle is > bad news, because the disk head has to divide its time > between synchronous WAL writes and asynchronous writes of the > rest of the files. That sounds right - could be tested by him turning fsync off, or by moving the WAL to a different spindle (note I'm not advocating running in production with fsync off). - Luke
