On May 29, 2013, at 8:56 PM, Stanley Iriele <[email protected]> wrote:
> On Wed, May 29, 2013 at 5:41 PM, Jens Alfke <[email protected]> wrote: > >> >> On May 29, 2013, at 5:23 PM, Stanley Iriele <[email protected]> >> wrote: >> >>> I've been using couchdb for a while now and I have had problems in the >> past >>> with having too many views in one design doc. what is the recommended >>> number of view per doc?..is 6 too many?...the documents inside could >>> potentially be updated quite frequently. >> >> I think it depends entirely on your data and how complex the view >> functions are. >> >> The thing to remember is that when CouchDB needs to update a view, it >> updates _every_ view in that design document. If you have some views that >> are only queried rarely, or have especially slow map/reduce functions, it >> can help to put them in their own design documents. >> >> —Jens > > > > Thanks..that makes sense...So..how do reduce functions fit into the > mix?..when are they updated?.basically if I throw reduce function in...is > that updated as well when all of the views are updated?..will that slow > down view generation? I don't really know if reduce functions are called > one the fly CouchDB does pre-compute some pieces of a reduce view. If you're querying the reduce view with group=false it can pre-compute the whole thing and deliver the result directly. If you're querying with group=true or group_level=N the situation is a bit more complicated. CouchDB still does a good bit of pre-computation, but it doesn't take the "boundaries" between keys into account. If you have a small number of unique keys in your view index then CouchDB can do a lot of the work ahead of time. If each key only appears in a couple of rows then CouchDB will essentially be doing ~all of the reduce work at query time for a group=true query. Cheers, Adam
