couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rogutės Sparnuotos <>
Subject Re: Database size seems off even after compaction runs.
Date Sat, 24 Dec 2011 01:32:40 GMT
Chris Stockton (2011-12-23 13:56):
> 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?

Again, you can't reclaim space taken by empty deleted documents (the ones
that have only the _id, _rev, _deleted fields), but you can reclaim space
if your documents were deleted with a body (more than the 3 fields above).

Do you know the ids of deleted documents? If you do, you can look at them:
$ curl '<db>/<doc_id>?rev=<rev>'
You can delete them again, this time without leaving any fields:
$ curl -X PUT '<db>/<doc_id>?rev=<rev>' -d '{"_deleted":true}'
Don't know if there is any way to find the ids of deleted documents,
except by watching the _changes feed beforehand (as Robert Newson

--  Rogutės Sparnuotos

View raw message