Re: Group Commit

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