Tom Lane wrote:
> Heikki Linnakangas <heikki@enterprisedb.com> writes:
>> I've been working on the patch to enhance our group commit behavior. The
>> patch is a dirty hack at the moment, but I'm settled on the algorithm
>> I'm going to use and I know the issues involved.
>> ...
>> The timeout is currently hard-coded at 1 ms.
>
> This is where my bogometer triggered. There's way too many platforms
> where 1 msec timeout is a sheer fantasy. If you cannot make it perform
> well with a 10-msec timeout then I don't think it's going to be at all
> portable.
>
> Now I know that newer Linux kernels tend to ship with 1KHz scheduler
> tick rate, so there's a useful set of platforms where you could make it
> work even so, but I'm not really satisfied with saying "this facility is
> only usable if you have a fast kernel tick rate" ...
The 1 ms timeout isn't essential for the algorithm. In fact, I chose it
arbitrarily; in the quick tests I did the length of the timeout didn't
seem to matter much. I'm running with CONFIG_HZ=250 kernel myself, which
means that the timeout is really 4 ms on my laptop.
I suspect the tick rate largely explains why the current commit_delay
isn't very good is that even though you specify it in microseconds, it
really waits a lot longer. With the proposed algorithm, the fsync is
started immediately when enough commit records have been inserted, so
the timeout only comes into play when the estimate for the group size is
too high.
With a higher-precision timer, we could vary not only the commit group
size but also the timeout.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com