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
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
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
