Jim C. Nasby wrote:
> On Fri, Mar 10, 2006 at 11:57:16PM -0800, David Lang wrote:
>> On Sat, 11 Mar 2006, Joost Kraaijeveld wrote:
>>
>>> On Fri, 2006-03-10 at 13:40 +0000, Richard Huxton wrote:
>>>> Your ATA disk is lying about disk caching being turned off. Assuming
>>>> each insert is in a separate transaction, then it's not going to do
>>>> 10,000 / 6 = 1667 transactions/sec - that's faster than it's rotational
>>>> speed.
>>> Could you explain the calculation? Why should the number of transactions
>>> be related to the rotational speed of the disk, without saying anything
>>> about the number of bytes per rotation?
>> each transaction requires a sync to the disk, a sync requires a real
>> write (which you then wait for), so you can only do one transaction per
>> rotation.
>
> But shouldn't it be possible to batch up WAL writes and syncs? In other
> words, if you have 5 transactions that all COMMIT at exactly the same
> time, it should be possible to get all 5 WAL pages (I'll assume each
> one generated a small enough change so as not to require multiple WAL
> pages) to the drive before the platter comes around to the right
> position. The drive should then be able to write all 5 at once. At
> least, theoretically...
I think you mean this...
http://www.postgresql.org/docs/8.1/static/runtime-config-wal.html
commit_delay (integer)
Time delay between writing a commit record to the WAL buffer and
flushing the buffer out to disk, in microseconds. A nonzero delay can
allow multiple transactions to be committed with only one fsync() system
call, if system load is high enough that additional transactions become
ready to commit within the given interval. But the delay is just wasted
if no other transactions become ready to commit. Therefore, the delay is
only performed if at least commit_siblings other transactions are active
at the instant that a server process has written its commit record. The
default is zero (no delay).
commit_siblings (integer)
Minimum number of concurrent open transactions to require before
performing the commit_delay delay. A larger value makes it more probable
that at least one other transaction will become ready to commit during
the delay interval. The default is five.
--
Richard Huxton
Archonet Ltd
