Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Message-ID: <427010381.5351265058618930.JavaMail.jira@brutus.apache.org>
Date: Mon, 1 Feb 2010 21:10:18 +0000 (UTC)
From: "Jan Lehnardt (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Subject: [jira] Updated: (COUCHDB-224) Improve B-Tree implementation
In-Reply-To: <667486799.1232744759642.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/COUCHDB-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Lehnardt updated COUCHDB-224:
---------------------------------

         Priority: Major  (was: Blocker)
    Fix Version/s:     (was: 0.11)
                   1.0

bumping to 1.1. for what it's worth, Robert Newson did some practical benchmaks and didn't see any performance issues with uncompacted databases. removing blocker status, too.

> Improve B-Tree implementation
> -----------------------------
>
>                 Key: COUCHDB-224
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-224
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: Database Core
>    Affects Versions: 0.8
>            Reporter: Jan Lehnardt
>            Assignee: Damien Katz
>             Fix For: 1.0
>
>
>  Also, the current Btree implementation isn't completely self balanacing. It
> misses a balancing condition, partially for efficiency (it's an expensive
> balancing operation), and for expediency. It was easier to not implement it and
> gets the general case perormance boost.
>  The thing about this is, the btree code can remain as is if the indexing
> compaction just recopies the map values (and back indexes) and recomputes the
> reduction values. That's a very simple design, however, if the btree is
> completely self balancing, then the btree can be copied on a node by node basis,
> instead of a value by value basis, and the reduction values need not be
> recomputed all. This will make the compaction significantly faster overall.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.