From user-return-17537-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Thu Aug 18 18:08:36 2011 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 0657380F8 for ; Thu, 18 Aug 2011 18:08:36 +0000 (UTC) Received: (qmail 11331 invoked by uid 500); 18 Aug 2011 18:08:34 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 11270 invoked by uid 500); 18 Aug 2011 18:08:33 -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 11262 invoked by uid 99); 18 Aug 2011 18:08:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Aug 2011 18:08:33 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of chrisstocktonaz@gmail.com designates 74.125.83.52 as permitted sender) Received: from [74.125.83.52] (HELO mail-gw0-f52.google.com) (74.125.83.52) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Aug 2011 18:08:27 +0000 Received: by gwj15 with SMTP id 15so1601802gwj.11 for ; Thu, 18 Aug 2011 11:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=N+ZT2XQie/KtSHATIPnQ3GMkYYB0QUC/Qi0ngfwXTYM=; b=eC1/7Rw3eEB6ltM3hyZ5c/btMbo5B8Hbgh6Xk7LLyJ9xiLUvO6Ud+IBQmCOM/SkGis 7ve2Bl+rj8/QL5kjutFYtx1aYhLoaRVSuFl83pidFbl4QgGYA5TaB3g5tAznMEpk8Rhg 4CW20lQ7zQiqWx4ydl/nKNLsoGQsDlPeCaEnE= MIME-Version: 1.0 Received: by 10.42.159.196 with SMTP id m4mr922549icx.407.1313690886342; Thu, 18 Aug 2011 11:08:06 -0700 (PDT) Received: by 10.42.178.197 with HTTP; Thu, 18 Aug 2011 11:08:06 -0700 (PDT) In-Reply-To: References: Date: Thu, 18 Aug 2011 11:08:06 -0700 Message-ID: Subject: Re: Bug or my lack of understanding? "Reduce output must shrink more rapidly" From: Chris Stockton To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Hello, On Wed, Aug 17, 2011 at 10:55 AM, Robert Newson wrote: > The reduce_limit heuristic is there to save you from writing bad > reduce functions that are destined to fail in production as document > count increases. The result of a reduce call should be strictly > smaller than the input size (and preferably a lot smaller). > > If the number of keys in the returned object is fixed, you'll probably > be fine, though testing with a sizeable number of documents (and > graphing the performance curve) will prove it. > > B. > Hello Robert, Basically that is what I'm confused about, the response is a fixed size statistical aggregation, it does not grow in length, only increments scalar values. The structure on the first pass is the same size as the last. I think the view exiting on the first iteration is undesired behavior and a higher sampling of data / slightly more forgiving algorithm should be put in place for this. If this simply won't happen or no one else agrees I will remove the reduce limit.. but I feel like that could be very dangerous and almost would rather create a patch for our CouchDB's before I did that. -Chris