On Nov 9, 2009, at 14:01, Paul Davis <[email protected]>
wrote:
In trunk the computation and index writing are split to take up to two
cores. It'd be theoretically possible to expand the mapping side to
use all available cores but most reports say that the btree writing
process is CPU bound, so any more than a single mapper would just be a
waste of resources.
Unfortunately, parallelizing the btree updates is rather non-trivial.
I've contemplated a few different methods for attempting it, but
nothing that has come of my limited self amusement in that respect.
HTH,
Paul Davis
Dear Paul,
I'm willing to help work on this, however, as you note, truely
concurrent updates to a tree are hard. I've been playing with subtree
locking, but 1) it doesn't work right now and 2) the root is still
temporarily locked, although it does generally reduce bottlenecks
somewhat.
I've been reading about highly concurrent trees, I'll send some links
when I get home.
~ Christopher
