"Jim Starkey" <jas@...> wrote:

>
> >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.

Fine.

> 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.

isc_dpb_no_garbage_collect, if always used, also tends to result in lower
overall performance for everyone, but this is required for some usage
patterns, including gbak. I think that this option would allow to serve
occasional critical transactions more effectively under heavy load (a kind
of OOB packets?)

As a slightly offtopic question - did you think about the defered commits
(in the meaning I presented in my first message)? It might be a good
solution for those preferring to get extra speed at the expense of decreased
(but still controlled) reliability?


Dmitry