I've cut a new version of the GIT patch I posted earlier, and collected
all my dispersed todo-lists, post-it notes, performance results,
supplementary patches etc. I had to a single web-page:
http://community.enterprisedb.com/git/
Perhaps the most interesting stuff apart from the patch itself is the
performance results. I've run some CPU bound tests to measure the extra
CPU overhead it causes. The CPU overhead is significant, the worst case
being a select of a single row from a table with just one integer column.
However, the I/O savings are also the greatest for that same test case,
as the table grows and the test becomes I/O bound. I don't have the
numbers now, but earlier runs showed that the duration of the test was
roughly halved, which makes sense because the patch reduced the index
size so that it fit in memory, reducing the number of physical I/Os
required per select from 2 to 1.
ISTM that if we want to enable GIT automatically, we need a way to
either reduce the CPU overhead, or have a smart heuristic to tune the
feature so that it's only enabled when it's beneficial.
Thoughts?
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com