couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Göran Krampe <>
Subject Re: Possible bug in indexer... (really)
Date Sun, 05 Jul 2009 08:05:05 GMT
Hi Paul!

Paul Davis wrote:
> 2009/7/4 Göran Krampe <>:
>> Adam Kocoloski wrote:
>>> Not sure if it's described, but it is by design.  The reduce function
>>> executes when the btree is modified.  We can't afford to cache KVs from an
>>> index update in memory regardless of size; we have to set some threshold
>>> when we flush them to disk.
>> And I presume you can't write KVs *without* doing the reduce?
>> When I wrote "described" I am referring to the blog post by Ricky Ho btw. It
>> seems to imply a strict ordering, map -> reduce -> rereduce. IIRC.
> That was probably just the theoretical aspect. Map's always happen
> first obviously, and then when the key/values are inserted into the
> btree during a flush the entire tree is built which means that > 0
> reduces are called and then re-reduces are run to fill out the tree.
> At the moment we aren't delaying re-reduce calls because it'd require
> a major overhaul to the btree code.

Right, so there is nothing preventing delaying the reduce and rereduce 
calls untl the end - except of course the problem of actually 
implementing it. Just want to understand.

regards, Göran

View raw message