Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of kowsik@gmail.com designates
 209.85.221.21 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=Wy2bNVPbzBlJI17Ls1Hi+A+bPyezMl8DZ1/rjBI407tjpjm2Gm89hLfYsCPpFJ9jg8
         KAtI8mmBaUAOPcgVHeavaf001j+KXixfIxiV66dUjXkISDgZFj+0+I/bxRNvS6DDECm5
         xTzcXGAltHDXImW85IbRKJG8sVTw6bdmX6Hk8=
MIME-Version: 1.0
Date: Fri, 23 Jan 2009 09:04:32 -0800
Message-ID: <7db9abd30901230904h17fc60c9i9c84a83396041b5@mail.gmail.com>
Subject: Compaction...
From: kowsik <kowsik@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

For the most part, I never have to look at Couch once its running
since the index generation, id generation, incremental indexing,
document updates all __just__ work. For pcapr.net, since the middle
tier is Helma (also Javascript), new views in the source are
automatically sync'd directly to couch. I can almost completely relax,
except...compaction.

Is it possible to do some kind of automatic compaction, similar to
auto growing hash tables based on collisions/density or garbage
collection? The best place to do this really is the db itself. With
this I never have to worry about file sizes growing indefinitely or
having to find the best time to compact the database.

This might mean, though, that compaction has higher priority than
writes. I guess it's a trade off.

Thoughts?

K.