incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: number of views pe design doc
Date Thu, 30 May 2013 02:29:34 GMT
On May 29, 2013, at 8:56 PM, Stanley Iriele <> wrote:

> On Wed, May 29, 2013 at 5:41 PM, Jens Alfke <> wrote:
>> On May 29, 2013, at 5:23 PM, Stanley Iriele <>
>> 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? 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 do reduce functions fit into the
> mix?..when are they updated?.basically if I throw reduce function
> 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
View raw message