Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 89544 invoked from network); 29 Apr 2009 19:29:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 29 Apr 2009 19:29:06 -0000 Received: (qmail 98574 invoked by uid 500); 29 Apr 2009 19:29:05 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 98499 invoked by uid 500); 29 Apr 2009 19:29:05 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 98489 invoked by uid 99); 29 Apr 2009 19:29:05 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Apr 2009 19:29:05 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.146.177 as permitted sender) Received: from [209.85.146.177] (HELO wa-out-1112.google.com) (209.85.146.177) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Apr 2009 19:28:56 +0000 Received: by wa-out-1112.google.com with SMTP id m38so620314waf.27 for ; Wed, 29 Apr 2009 12:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=DaiOTikhFvYwC96A3QL6KGOUOuHgFmfI6pjIlg772Jo=; b=a9U9rlJCyL90/jtnyfGdmD1JV6s1Cunckf5LyhgMj1dgQMMTJpSwj/jmfhI8HBdL4E tena5mhMAo4MLFbeHy7LqTWKQfDzke64CgH70HPDINWjR8+vM0mCjp6kdE49muXrncAp JvTnkmWCjI1AXys4U4E3ECqtp5Q3Ewqgd/UPE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=UXHEltSt+j+ZEl6oaMoAmqyxo6Kqm6v0kw1U+Az1AxzMXhuVzRxDHjosaHKnDL7+rM abrluu8NLVti8PxeywOi1wgI/kawUAbkd0Ns7og3IoMKdSnSyPnWcdkjJ9igg0cyh0by 2YYUYmmmA40Q9M8oeyYs04yJsC6m9m3ZHBL4E= Received: by 10.114.192.3 with SMTP id p3mr693974waf.25.1241033315308; Wed, 29 Apr 2009 12:28:35 -0700 (PDT) Received: from ?10.71.0.44? (216.112.110.172.ptr.us.xo.net [216.112.110.172]) by mx.google.com with ESMTPS id t1sm5916632poh.9.2009.04.29.12.28.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Apr 2009 12:28:34 -0700 (PDT) Message-ID: <49F8AA60.7020207@gmail.com> Date: Wed, 29 Apr 2009 12:28:32 -0700 From: Paul Davis User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: user@couchdb.apache.org Subject: Re: Array being chunked in reduce References: <26650b020904291210q28d6a62bkf4a2692d101c4798@mail.gmail.com> In-Reply-To: <26650b020904291210q28d6a62bkf4a2692d101c4798@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Ross Bates wrote: > Hi All - I have about 600 of documents with 3 attributes: > > parent, child, level > > When I run the following map/reduce everything looks correct at first in > that I get an array back where the key is the level and the value is a > collection of arrays that have share the same level value. So if there were > 5 unique levels there would be 5 rows > > function(doc) { > emit( parseInt(doc.level), [doc.child,doc.parent]); > }; > > > function(a,b){ > return b; > } > > > The problem is that when I run this on a larger data set the value array > starts getting chunked into arbitrary sizes (50, 83, etc....) When I say > chunked, the row has a bunch of additional nested arrays to store the > key/value. > > Is there some sort of max array size imposed by couch db? > > Many Thanks, > Ross > > Ross, Firstly, the chunked bits you're seeing is couchdb running rereduce on your reduce output. The full signature of a reduce function is: function(keys, values, rereduce) Where rereduce is a boolean that flags if the function is being called on its own output. Also, the function as you have it would eventually tip over as its returning too much data. For your particular use case I would suggest omitting the reduce function entirely and then doing a selection on the map and any post-processing client side. HTH, Paul Davis