couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Vander Wilt <>
Subject Re: Database size seems off even after compaction runs.
Date Mon, 26 Dec 2011 18:10:54 GMT
On Dec 23, 2011, at 2:56 PM, Chris Stockton wrote:
> Hello,
> On Fri, Dec 23, 2011 at 5:48 AM, CGS <> wrote:
>> Hi,
>> Sorry to interfere with such a question, but why don't you work with a
>> buffer database? I mean, make a replica to another database which filters
>> out the deleted documents. In such way you can clean all your databases and
>> you use temporary some extra-space (only during the "cleaning" process).
>> Another idea would be to use two databases: one active and one inactive at
>> the given time. That means, you move the data from one to the other,
>> filtering out the deleted documents, and when it's over, you switch to the
>> newly constructed database, while the other gets emptied (deleted and
>> re-created). Just my 2c opinions.
>> CGS
> Thanks everyone for the various feedback. Now the information I have
> gathered is the disk utilization we are seeing is simply from the
> deleted documents.
> The question I have yet to see answered (perhaps because it simply
> isn't possible) is how to reclaim this space?

One potential option, not sure if it's ideal for your use case, could be using the purge command
on the deleted documents, followed by a compaction.

What this does is *completely forget* the document in the btree (no "tombstones"):

POST /db/_purge -d '{"id1":["rev1"], "id2":["rev2"]}'

This will thwart replication, i.e. this deletion will not propagate and the document may get
pushed back into existence if another database has it.

View raw message