Re: COPY into table too slow with index: now an I/O

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