Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jchris@gmail.com designates
 74.125.46.31 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:date:x-google-sender-auth:message-id:subject
         :from:to:content-type:content-transfer-encoding;
        b=tzxL5X1gH2EThs3d7r8t3G8i4RLXUxuMmaiqYp1J0OSuIbJmfmQCp30LTKPE82bX8/
         sQCQJTlU0Ri7CHgQ7ZvzwK6pwnGuT8tqHCpfOV01TQo0mCTp+vyEpE/zetLOr5PRaMqu
         sEx0fSRMA97FmOWEh7OxuOBSKWJ7xm73q77jM=
MIME-Version: 1.0
Sender: jchris@gmail.com
Date: Mon, 4 May 2009 15:08:38 -0700
Message-ID: <e282921e0905041508t5d534e62xda338e98822f2659@mail.gmail.com>
Subject: reduce_limit error
From: Chris Anderson <jchris@apache.org>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Devs,

I'm checking in a patch that should cut down on the number of mailing
list questions asking why a particular reduce function is hella slow.
Essentially the patch throws an error if the reduce function return
value is not at least half the size of the values array that was
passed in. (The check is skipped if the size is below a fixed amount,
200 bytes for now).

I expect this heuristic will need fine tuning. Ideally we'd never
raise the error on "good" reduces, and always raise it on
"ill-conceived" ones. If you hit the error on a reduce that seems like
it should be considered good, please ping the list so we have an
opportunity to fine-tune.

There is a config option:

[query_server_config]
reduce_limit = true

changing this to false will revert to the old behavior. Ideally very
few applications will require this config change, so if you find
yourself changing this setting, it's a sign you should mail the list.

-- 
Chris Anderson
http://jchrisa.net
http://couch.io