Dmitry Yemanov wrote:

>"Jim Starkey" <jas@...> wrote:
>
>
>>I'll try it again. A call to isc_commit_transaction waits until the
>>next group commit cycle. On average, it will incur a cycle/2 latency.
>>This must be balanced against the system cost of avoidable write
>>
>>
>operations.
>
>
>Can we suppose scenarios when even 20-50 ms delay on commit is unacceptable?
>If so, may I suggest that a zero config option means no group commit? Or
>perhaps we may introduce isc_tpb_no_group_commit causing transaction to
>flush its buffers immediately?
>

Yes to all. The prototype already interprets a zero internal as no
group commit. Because a group commit does exactly the same work as a
regular commit, mixed group and individual commits are not a problem --
worst case, a few extra tip and/or header writes.

But it's an interesting philosophical question as to whether you offer
individual transactions the option of faster service at the expense of
other transactions, and an option, if always used, would result in lower
performance for everyone.

>
>Do you want to reuse the cache writer thread for this purpose or add a new
>one?
>

No, a clean implementation without undebugged baggage.

>
>
>

[Non-text portions of this message have been removed]