Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 8999 invoked from network); 21 Jan 2009 01:47:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 21 Jan 2009 01:47:57 -0000 Received: (qmail 40136 invoked by uid 500); 21 Jan 2009 01:47:50 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 40094 invoked by uid 500); 21 Jan 2009 01:47:50 -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 40083 invoked by uid 500); 21 Jan 2009 01:47:50 -0000 Delivered-To: apmail-incubator-couchdb-user@incubator.apache.org Received: (qmail 40080 invoked by uid 99); 21 Jan 2009 01:47:50 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Jan 2009 17:47:50 -0800 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of awolff@gmail.com designates 209.85.221.10 as permitted sender) Received: from [209.85.221.10] (HELO mail-qy0-f10.google.com) (209.85.221.10) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Jan 2009 01:47:42 +0000 Received: by qyk3 with SMTP id 3so3742791qyk.12 for ; Tue, 20 Jan 2009 17:47:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=a0XUPUACZNkapRp4zddTcJHAixqQ7LtVlipDtvDKoZ4=; b=g4V9vDpSeyFrnw/p7qfd5EnDRdpqINbYKSrnfvcUCEUYkgC5Kk9mxtgmSiRipVBnWo 6grNCdqMd4V6uf29AmUtbvaa9L1n3c9QYkv6yPJ+nIxkohljOAPisR3gREfiZi50aPfa 7sp04+H9W1rIIFr/Zj2hrmalaMxKtYaj9kZc0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Ar2dhPcdqZH5p75jixg5hGwVV9QAFyJBkRi+5b744oOeLqAVARN+ZDRkt28sGyIYws BvsYb44CHMRydW9oDjlHKh487p+UqeEUmwoSz4VugzZI/4hmkIvgWSDB4WvM9cMUqSTV TyXmNPICemzv3FSWc4hrRe+p72eT+tJSmz8v8= MIME-Version: 1.0 Received: by 10.214.10.4 with SMTP id 4mr8485284qaj.196.1232502436210; Tue, 20 Jan 2009 17:47:16 -0800 (PST) Date: Tue, 20 Jan 2009 17:47:16 -0800 Message-ID: Subject: reduce/rereduce confusion From: Adam Wolff To: couchdb-user@incubator.apache.org Content-Type: multipart/alternative; boundary=0015175cd600e52a540460f45550 X-Virus-Checked: Checked by ClamAV on apache.org --0015175cd600e52a540460f45550 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi everyone,I'm really excited about CouchDB and I've started playing with it. I get all of it, except for reduce, and especially re-reduce. My first question is: how does CouchDB maintain all the separate output for a given key from the map function? I mean: given a simple reduce that just sums results, how does couch maintain separate results for each possible key/key range that can be given as input to that view? My second question: when and why does rereduce get called? Is this simply to allow the server to chunk the processing, or is there semantic meaning to it? I had assumed the former -- it's just a way of limiting the size of the input to the reduce function -- but then this really confused me: if I log each time my reduce function gets called, I see that the last time it's called, it's with rereduce=false. How is this possible? Don't all the results have to be funneled through rereduce to produce a single result value? Any help here would be much appreciated. If there's a resource on the web I should look at, please send it my way. Thanks! A --0015175cd600e52a540460f45550--