Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Message-ID: <1271935216.1238883072963.JavaMail.jira@brutus>
Date: Sat, 4 Apr 2009 15:11:12 -0700 (PDT)
From: "Adam Kocoloski (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Subject: [jira] Commented: (COUCHDB-92) Have compaction work on view indexes
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/COUCHDB-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12695794#action_12695794 ] 

Adam Kocoloski commented on COUCHDB-92:
---------------------------------------

Actually, I think it'd be better if the interface was

HTTP
POST /dbname/_compact/groupname => 202 {"ok":true}

Erlang
couch_view_compactor:start_compact(<<"dbname">>, <<"groupname">>) -> ok

If no one objects I'll add this trunk before 0.10

> Have compaction work on view indexes
> ------------------------------------
>
>                 Key: COUCHDB-92
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-92
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: JavaScript View Server
>    Affects Versions: 0.8
>            Reporter: Jan Lehnardt
>             Fix For: 0.10
>
>
> Right now, view indexes just grow and grow with each new index update. Since they are just indexes, and not the data itself, compaction is simply a matter of deleting the index files.
> 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.