Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 87870 invoked from network); 3 Oct 2009 19:43:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 3 Oct 2009 19:43:59 -0000 Received: (qmail 34459 invoked by uid 500); 3 Oct 2009 19:43:57 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 34377 invoked by uid 500); 3 Oct 2009 19:43:57 -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 34365 invoked by uid 99); 3 Oct 2009 19:43:57 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 Oct 2009 19:43:57 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.217.220 as permitted sender) Received: from [209.85.217.220] (HELO mail-gx0-f220.google.com) (209.85.217.220) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 Oct 2009 19:43:48 +0000 Received: by gxk20 with SMTP id 20so2265064gxk.12 for ; Sat, 03 Oct 2009 12:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=ExvhvSNgzJRy9l80RQGPVf2FT2ZPS0Ad3UV9vPEdmkM=; b=OWp0FQGP1AGwwK50zsKWNpkhQ4GlcPEzrVxzZlf6PIHPycGDwiuusRvb85HySZzFl8 CuIpltoavPaI34v0dRz5O5C+59LySsAxr299OJUpVDw3SmAjxaGfl8/O1f62tGeotGtw w75iu5lBfvkqUTB3uR/vPeQvKdIXbLfs8BpZA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=IEEqKBqKw4MZbl3xytoAc2YN6+YhM2EhD9hB3wnL3b5KQyIIrIxoHvwI7s3bqYZox9 TEiOn0BG3ekyEpn4xyTMk0HfbP+Ql0rxzJqyIjlH/wUY1wfW1jhGmDIuv7nxZiWr6Gdb S8WexYs4AuU4958uz2DHuvk5pR7EV1URdfk0w= MIME-Version: 1.0 Received: by 10.101.44.1 with SMTP id w1mr4190280anj.113.1254599007066; Sat, 03 Oct 2009 12:43:27 -0700 (PDT) In-Reply-To: References: Date: Sat, 3 Oct 2009 15:43:27 -0400 Message-ID: Subject: Re: Short keys == faster lookups? From: Paul Davis To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org Technically speaking you could probably engineer keys to exhibit bad collation behavior, but that'd take some thought. Something like 1KiB or larger keys with long identical prefixes. That said, measure twice, code once. I've never heard any numbers on it. Paul Davis On Sat, Oct 3, 2009 at 9:29 AM, Per Ejeklint wrote: > Please excuse a silly question from a newbie. I have a db that grows pretty > fast (data measurements done every minute all year around). I wonder what I > save if I mangle keys to be as short as possible. Like instead of calling > things "temp_outside" I rename them to "t_o" or something like it. The size > of the db will of course shrink, but will it do anything for indexing/lookup > speed when I search in the db? > > /Per >