Return-Path: Delivered-To: apmail-incubator-couchdb-user-archive@locus.apache.org Received: (qmail 6051 invoked from network); 27 Oct 2008 16:16:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 27 Oct 2008 16:16:20 -0000 Received: (qmail 69600 invoked by uid 500); 27 Oct 2008 16:16:22 -0000 Delivered-To: apmail-incubator-couchdb-user-archive@incubator.apache.org Received: (qmail 69533 invoked by uid 500); 27 Oct 2008 16:16:22 -0000 Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: couchdb-user@incubator.apache.org Delivered-To: mailing list couchdb-user@incubator.apache.org Received: (qmail 69522 invoked by uid 99); 27 Oct 2008 16:16:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Oct 2008 09:16:22 -0700 X-ASF-Spam-Status: No, hits=3.2 required=10.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.217.13] (HELO mail-gx0-f13.google.com) (209.85.217.13) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Oct 2008 16:15:10 +0000 Received: by gxk6 with SMTP id 6so3700878gxk.12 for ; Mon, 27 Oct 2008 09:14:48 -0700 (PDT) Received: by 10.90.83.2 with SMTP id g2mr4861335agb.7.1225124088360; Mon, 27 Oct 2008 09:14:48 -0700 (PDT) Received: by 10.90.117.7 with HTTP; Mon, 27 Oct 2008 09:14:48 -0700 (PDT) Message-ID: <64a10fff0810270914q2cbab0t35eac061830933be@mail.gmail.com> Date: Mon, 27 Oct 2008 12:14:48 -0400 From: "Dean Landolt" To: couchdb-user@incubator.apache.org Subject: Re: Efficient view design question In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_43348_7938875.1225124088348" References: <1ac9e0120810261220h1528d201ta638c181b654829@mail.gmail.com> <0CFA983F-A3EA-43F5-9B80-76F818F546A4@apache.org> <4905A415.2090208@tangentlabs.co.uk> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_43348_7938875.1225124088348 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Oct 27, 2008 at 11:53 AM, Ben Nevile wrote: > > > > First off to alay your main concern, view indexes are not completely > > regenerated on each update. Its only a diff. > > > > Presumably reduce operations have to operate on the entire set every time? > > Ben > I may be completely off base here, but that's where rereduce comes. I'd done a little profiling on reduce a while back, and it looks as though it lumps reductions into manageable chunks of approximately 20 or so emitted map records. I don't know what kind of magic it does behind the scenes to determine when to tease apart these chunks, but something's going on where only affected records get broken apart, otherwise the whole chunk gets passed through as an object. So yes, a reduce operates on the whole set, but in very large summary chunks. Someone correct me if I'm wrong (please!) -- I've been scratching my head about the internals of reduce for a while now, and still haven't found a very illuminating description of the process. ------=_Part_43348_7938875.1225124088348--