From couchdb-user-return-1638-apmail-incubator-couchdb-user-archive=incubator.apache.org@incubator.apache.org Mon Oct 27 16:55:15 2008 Return-Path: Delivered-To: apmail-incubator-couchdb-user-archive@locus.apache.org Received: (qmail 28793 invoked from network); 27 Oct 2008 16:55:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 27 Oct 2008 16:55:15 -0000 Received: (qmail 40703 invoked by uid 500); 27 Oct 2008 16:55:19 -0000 Delivered-To: apmail-incubator-couchdb-user-archive@incubator.apache.org Received: (qmail 40305 invoked by uid 500); 27 Oct 2008 16:55:17 -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 40294 invoked by uid 99); 27 Oct 2008 16:55:17 -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:55:17 -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 [72.14.220.152] (HELO fg-out-1718.google.com) (72.14.220.152) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Oct 2008 16:54:05 +0000 Received: by fg-out-1718.google.com with SMTP id l26so1913460fgb.26 for ; Mon, 27 Oct 2008 09:54:32 -0700 (PDT) Received: by 10.187.247.15 with SMTP id z15mr560062far.71.1225126471255; Mon, 27 Oct 2008 09:54:31 -0700 (PDT) Received: by 10.187.159.10 with HTTP; Mon, 27 Oct 2008 09:54:31 -0700 (PDT) Message-ID: Date: Mon, 27 Oct 2008 09:54:31 -0700 From: "Ben Nevile" To: couchdb-user@incubator.apache.org Subject: Re: Efficient view design question In-Reply-To: <11F243A6-EF0A-414F-A89E-6AAB954296E4@apache.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_24692_19523444.1225126471244" References: <1ac9e0120810261220h1528d201ta638c181b654829@mail.gmail.com> <0CFA983F-A3EA-43F5-9B80-76F818F546A4@apache.org> <4905A415.2090208@tangentlabs.co.uk> <137D1127-02E5-40BC-9432-B3CF4172148B@apache.org> <64a10fff0810270915g23cfa06fs42c9888a5bd4e6a4@mail.gmail.com> <11F243A6-EF0A-414F-A89E-6AAB954296E4@apache.org> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_24692_19523444.1225126471244 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks Jan, that article answers a lot of questions. re the following quote: "There is also an option (under development) to immediately return a stale copy of the view in case the client can tolerate that." My application needs to do hundreds of thousands of index updates for every incoming piece of data, so being able to return a stale result is critical. Where can I find some documentation about this option? Ben On Mon, Oct 27, 2008 at 9:30 AM, Jan Lehnardt wrote: > > On Oct 27, 2008, at 17:15, Dean Landolt wrote: > > On Mon, Oct 27, 2008 at 12:13 PM, Jan Lehnardt wrote: >> >> >>> On Oct 27, 2008, at 16:53, 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? >>>> >>>> >>> Nope, reduce results are stored in the btree back nodes. >>> >> >> >> Or...that. >> >> Jan -- can you speak to what that means? Back nodes? >> > > See http://horicky.blogspot.com/2008/10/couchdb-implementation.html > > Cheers > Jan > -- > ------=_Part_24692_19523444.1225126471244--