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
