Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> 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

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

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to