From user-return-22006-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Thu Sep 6 20:35:17 2012 Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A718992EC for ; Thu, 6 Sep 2012 20:35:17 +0000 (UTC) Received: (qmail 84356 invoked by uid 500); 6 Sep 2012 20:35:16 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 84324 invoked by uid 500); 6 Sep 2012 20:35:16 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 84312 invoked by uid 99); 6 Sep 2012 20:35:16 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Sep 2012 20:35:16 +0000 Received: from localhost (HELO [192.168.1.5]) (127.0.0.1) (smtp-auth username rnewson, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Sep 2012 20:35:15 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1278) Subject: Re: dropping revision records From: Robert Newson In-Reply-To: Date: Thu, 6 Sep 2012 21:35:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: user@couchdb.apache.org X-Mailer: Apple Mail (2.1278) I think Tim was clear that this was post-compaction, though. The 2gb is = the historic _rev values for all these documents. You could lower _rev_limit and recompact to flush these out. B. On 6 Sep 2012, at 20:46, Benoit Chesneau wrote: > On Thu, Sep 6, 2012 at 4:18 PM, Tim Tisdall wrote: >> I had a database of about 10.8gb with almost 15 million records which >> was fully compacted. I had to back it up by dumping all the JSON and >> then restoring it by inserting it back in. After it was done and I >> compacted it the database was now only 8.8gb! I shed 2gb because of >> dropping the revision stubs still in the database. This is likely >> because each record had about 6 revisions (so around 90 million >> stubs). All of this is understandable, but 2gb isn't really >> negligible when running on a virtualized instance of 35gb. The >> problem, though, is the method I used to dump to JSON and place it >> back into couchdb took almost 12hrs! >>=20 >> Is there a way to drop all of the revision stubs and reset the >> document's revision tags back to "1-" values? I know this would >> completely break any kind of replication, but in this instance I am >> not doing any. >=20 > It would break more than the replication. Compacting your database is > the solution. >=20 > - beno=EEt