Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2FEF94CDA for ; Sun, 19 Jun 2011 14:08:13 +0000 (UTC) Received: (qmail 94521 invoked by uid 500); 19 Jun 2011 14:08:11 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 94486 invoked by uid 500); 19 Jun 2011 14:08:11 -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 94478 invoked by uid 99); 19 Jun 2011 14:08:11 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 19 Jun 2011 14:08:11 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of djc.ochtman@gmail.com designates 209.85.216.173 as permitted sender) Received: from [209.85.216.173] (HELO mail-qy0-f173.google.com) (209.85.216.173) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 19 Jun 2011 14:08:03 +0000 Received: by qyk10 with SMTP id 10so1103069qyk.11 for ; Sun, 19 Jun 2011 07:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:content-type; bh=h9dLvqo8mNxpwpInsKk5ZmC72o8AGoJv2wlMalyYGpY=; b=N0GVsqGiN66wn0F4baZOnuqdOn5YAp5S2bkJX+2f2X1NpYbSWMW1kWuFhGtaMtTs90 k7XtgiSY6M9G6su676YrXhcYlLfB3LLdBU6PysOn17gZFqE5+IAg7/qVoIjHTKLobilR 6tfziQ22VOJFLyKKkrD99Bjuzc/CKJHLvHQcc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=SaXNnxCgVF4Fw5yp233HeG7ZvQdaCCfqkQiWuK4Y4n0WDqEJ3dUPbFwQk6CifPxvDL NVOQTh7lY0uFYIpJ1oI1OP7zT21kCIpYgqcUsHbKDOcwdBxyPu+XrGjWOEjcHDIPqJA3 BHvPZDeMqoORj4BwbHSF8pZQJ/8NPFa1zGV2A= Received: by 10.229.212.2 with SMTP id gq2mr2140737qcb.271.1308492462537; Sun, 19 Jun 2011 07:07:42 -0700 (PDT) MIME-Version: 1.0 Sender: djc.ochtman@gmail.com Received: by 10.229.89.67 with HTTP; Sun, 19 Jun 2011 07:07:20 -0700 (PDT) In-Reply-To: References: From: Dirkjan Ochtman Date: Sun, 19 Jun 2011 16:07:20 +0200 X-Google-Sender-Auth: -P26ozKFjyXmNlW_8PqVv3Ke10A Message-ID: Subject: Re: Is reduce not incremental? To: user@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org On Sun, Jun 19, 2011 at 10:10, Aroj George wrote: > Yes, the map step is not redone, but I thought the reduce values are cached > in the internal non-leaf nodes? > Why then does Couch rerun the reduce every time for the exact same query ( > same group level etc..) AFAIK, the reduce results are cached in a tree-shaped cache on-disk, where each member has the reduced results from all its child nodes. If your query does not exactly match a single parent node, the reduce query will have to skim a few parent nodes and reduce their results further (i.e. with rereduce=True). This certainly doesn't mean that each reduce query will have to calculate the full results from reducing all the map results, though. Cheers, Dirkjan