On Thu, Sep 17, 2009 at 6:45 PM, Delta 2038 <[email protected]> wrote: > On Wed, Sep 16, 2009 at 6:42 PM, Chris Anderson <[email protected]> wrote: > >> Of course, the usual include_docs performance caveats apply, but this >> time we get a feature out of it! >> > > A bit off-topic here, but would you elaborate maybe just a little bit the > include_docs performance caveats? I assume that it involves reading another > view to grab the documents since they are not present in the current view? > We are interested in learning how much of a performance hit it actually > incurs. We could set up some load tests ourselves to find out, but if you > already have some pretty good idea... :) >
You've basically got it. In a nutshell, when using ?include_docs you have to read from a different location on disk and navigate the document id btree. The alternative is to emit the doc as part of the value so that reads are faster (at the expense of slower builds). I haven't seen any concrete numbers on the tradeoffs. Generally speaking if you're only wanting part of a doc, its probably best to emit just that part. Granted if that part is most of the doc, and its a big doc, it could cause a noticeable impact on view builds. I'd be interested in any numbers you generate exploring the difference. Paul Davis
