couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Joseph Davis <paul.joseph.da...@gmail.com>
Subject Re: VIEW Performance Testing Help
Date Wed, 04 Aug 2010 01:58:29 GMT




On Aug 3, 2010, at 7:31 PM, Steven Prentice <steven.prentice.87@gmail.com> wrote:

> Hey Couchinators!
> 
> My friend and I are trying to test the impact that views have on the size of
> the database and have a few questions...
> 
> 1. if the value of a view is set to 'doc' does that mean that the leaves of
> the view B-Tree are now documents or are they simply pointers to the
> document leaves in the database B-Tree?
> i.e would the summed memory of all of the values in the view be equal to the
> size of the database (ignoreing revisions)?

Whatever you emit as a value is stored  in the btree. So if you emit an entire document it
is stored completely in that view. A way to avoid this is to use the include_docs=true parameter
but it has some read performance trade offs because it's a lookup per view row. The best idea
is to only emit what's actually needed. 


> 2. also we would like to know if the database size that is displayed in
> futon includes the size of the views?

Unless I missed that commit, no, db size is the size of just the .couch file. 

> 3. Oh also, Revisions...is a revision an entire document or does a revision
> only track changes in a document?

Neither. A revision is just the string-id pair (More precisely it's a node in the revision
tree, but it still has zero info on actual document content). That's all that will remain
on disk after a compaction. Because we're tail append the previous entire documents remain
on disk until compaction. To illustrate, we've had discussions on removing access to old revisions
and renaming revision to something else that doesn't make people think they'll always have
access to old versions of a document. 

> Cheers
> Steve + Adam

HTH,
Paul Davis
Mime
View raw message