incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <>
Subject Re: Incremental map/reduce
Date Sat, 31 Jan 2009 21:00:48 GMT
On Fri, Jan 30, 2009 at 10:32:15AM -0800, Chris Anderson wrote:
> Once you understand how normal reduce queries (with group=false) work,
> eg: those that return a single reduction value for whatever key-range
> you specify, group_level queries are not more complex. Group_level
> queries are essentially a macro, which run one normal (group=false)
> reduce query automatically for each interval on a set of intervals as
> defined by the level.

Ah - it was new to me that map/reduce queries with group=false could run
over arbitary key intervals:

$ kurl 'http://localhost:5984/maptest/_view/test/sum'
$ kurl 'http://localhost:5984/maptest/_view/test/sum?startkey="doc3"'
$ kurl 'http://localhost:5984/maptest/_view/test/sum?startkey="doc3"&endkey="doc5"'

This means that couchdb *must* be performing the reduce part of the query
on-demand, as opposed to keeping precomputed values stored like the map

In SQL terms, this is like "count(*)" doing an index scan, rather than
having the answer precomputed in a materialised view. And suddenly the
various forms of reduce make much more sense.

However at it says:

"This requirement of reduce functions allows CouchDB to store off
intermediated reductions directly into inner nodes of btree indexes, and the
view index updates and retrievals will have logarithmic cost. It also allows
the indexes to be spread across machines and reduced at query time with
logarithmic cost."

Is storing the reductions a planned future feature, rather than describing
how it works today?

Sorry to keep asking, but I'm going to try to update the wiki in as accurate
a way as I can.



View raw message