Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 56462 invoked from network); 9 Feb 2009 15:07:35 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Feb 2009 15:07:35 -0000 Received: (qmail 66449 invoked by uid 500); 9 Feb 2009 15:07:35 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 66132 invoked by uid 500); 9 Feb 2009 15:07:34 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 66121 invoked by uid 99); 9 Feb 2009 15:07:33 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Feb 2009 07:07:33 -0800 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=FS_REPLICA,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.68.5.17] (HELO relay03.pair.com) (209.68.5.17) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 09 Feb 2009 15:07:24 +0000 Received: (qmail 82055 invoked from network); 9 Feb 2009 15:07:03 -0000 Received: from 96.33.90.152 (HELO ?192.168.1.195?) (96.33.90.152) by relay03.pair.com with SMTP; 9 Feb 2009 15:07:03 -0000 X-pair-Authenticated: 96.33.90.152 Message-Id: <8B0A69AE-65FE-4D7A-BC17-2D406E5890B5@apache.org> From: Damien Katz To: dev@couchdb.apache.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: proposed replication rev history changes Date: Mon, 9 Feb 2009 10:07:03 -0500 References: <5B2D5ED2-6B85-41D7-BA78-3DD4BE7AFE13@apache.org> <35C260B6-A77A-47C4-9A54-64765556007C@gmail.com> <989322F0-E376-43F4-8DCF-123EEB36181D@apache.org> X-Mailer: Apple Mail (2.930.3) X-Virus-Checked: Checked by ClamAV on apache.org On Feb 9, 2009, at 12:54 AM, Adam Kocoloski wrote: > On Feb 9, 2009, at 12:40 AM, Damien Katz wrote: > >>> Or Couch could switch to a 64 bit space for the revision IDs ;-) >> >> There is nothing preventing larger revs (or even non-integer revs) >> as it's just stored as a string (real efficient I know). The size >> could easily be a server or database setting. >> >> -Damien > > Hah, I noticed that but wasn't going to bring it up now. If the > file format is going to change I'd vote for being more efficient > about the space usage. No sense in throwing away 60% of the bytes > each time a revision is stored on disk. Best, > Sure, but it's not necessary to change the file format just because we save it in a more compact format. We are saving Erlang terms which also contain type information, so all you need some extra logic when reading from disk to convert values to a canonical format. So while there is no need to optimize it now, there is also no good reason to not do it either. So feel free to work on it, it should make the internal indexes smaller and faster. -Damien