couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Couchdb Wiki] Update of "Introduction to CouchDB views" by BrianCandler
Date Sat, 31 Jan 2009 21:53:46 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The following page has been changed by BrianCandler:
http://wiki.apache.org/couchdb/Introduction_to_CouchDB_views

The comment on the change is:
Clarify behaviour of reduce queries across ranges of keys

------------------------------------------------------------------------------
  See HttpViewApi to learn how to work with views. ["View_Snippets"] contain a few examples.
  
  == Grouping ==
- 
- The output of the map function is precomputed and stored on disk in a B-tree. However for
now, the output of the reduce function is calculated 'on demand' from this stored data, rather
than being stored itself.
  
  The basic reduce operation with group=false (the default over HTTP) is to reduce to a single
value. But by using startkey and endkey, you can get the summary value for any key interval.
  
@@ -176, +174 @@

  group=true is the conceptual equivalent of group_level=exact, so
  CouchDB runs a reduce per unique key in the map row set.
  
+ Note: map and reduce results are precomputed and stored in a btree.
+ However, the intermediate reduction values are cached
+ according to the btree structure, instead of according to the query
+ params. So unless your range happens to match exactly the keys
+ underneath a given inner node, you'll end up running at least one
+ javascript reduction per reduce query. A group=true query effectively
+ runs multiple reduce queries, so you may find it to be slower than
+ you expect.
+ 
+ There is more detail in [http://horicky.blogspot.com/2008/10/couchdb-implementation.html
this blog posting]
+ under the heading "Query Processing"
+ 
  == Restrictions on map and reduce functions ==
  
  The restriction on map functions is that they must be referentially transparent. That is,
given the same input document, they will always emit the same key/value pairs. This allows
CouchDB views to be updated incrementally, only reindexing the documents that have changed
since the last index update.

Mime
View raw message