Merge join performance
It seems that the page-at-a-time-index-scan patch applied in the spring
caused a slight performance regression to merge joins. The btree
mark/restore became much more expensive, as btmarkpos now has to copy
the array of item pointers retrieved from the current index page. That
adds up, because merge join calls markpos for every tuple.
We can make markpos fast, if we make the copy lazily in _bt_steppage,
see attached patch.
I did some micro-benchmarking of merge join performance, see attached
test. Test results, on my laptop:
8_1_STABLE: 1.77 s
HEAD, with patch: 1.65 s
HEAD, without patch: 2.46 s
The results are pretty stable, within 0.1 s.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Heikki Linnakangas <heikki@enterprisedb.com> writes:
We can make markpos fast, if we make the copy lazily in _bt_steppage,
Nice hack. Getting rid of the buffer refcount manipulations is probably
even more useful than avoiding the memcpy.
I did some micro-benchmarking of merge join performance, see attached
test. Test results, on my laptop:
8_1_STABLE: 1.77 s
HEAD, with patch: 1.65 s
HEAD, without patch: 2.46 s
Hm, I don't see a performance regression on my machine, but there is a
measureable improvement with the patch:
8.1 branch: 10.6 s
CVS HEAD: 10.1 s
w/patch: 9.3 s
Patch applied ...
regards, tom lane