From user-return-22016-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Fri Sep 7 00:51:44 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 B9679D350 for ; Fri, 7 Sep 2012 00:51:44 +0000 (UTC) Received: (qmail 48861 invoked by uid 500); 7 Sep 2012 00:51:43 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 48819 invoked by uid 500); 7 Sep 2012 00:51:43 -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 48804 invoked by uid 99); 7 Sep 2012 00:51:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Sep 2012 00:51:43 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FSL_RCVD_USER,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of tisdall@gmail.com designates 209.85.217.180 as permitted sender) Received: from [209.85.217.180] (HELO mail-lb0-f180.google.com) (209.85.217.180) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Sep 2012 00:51:36 +0000 Received: by lbon10 with SMTP id n10so1423403lbo.11 for ; Thu, 06 Sep 2012 17:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=hpV8whAlPrtf8Uvn6hGGgGZAwfImB2pWKEkfXNfZgrE=; b=LnUDAkTZeZYliDqUbRh68KATFMcQCElxjz/0J3IJE4lJHrCKIkqvwCEF5JPn9WBWUs GkFLi8bl0eMzkXE1hzAmRaMLz03TA+4Jm5+TnYKvKFXDlXxhhBnjLBasO8NHsznIteor 0keNlaGQaT2chAMzknPOxAbswmdBZm5XoxTYBSPuoZ/dpNopOA8ua/5I2sWl6qD9XkQl k6qfCaIpUU/rh95RLQFS+OVkMfRJd1ICmw/CRj10b6qpXAetPhrs0hJChXm690n8+rXA oisvCRJVu9d2N2lZZ/zf3oyTmAo84Ru34Ff8XwYvTlVVUkBgNqhzrEHKDi7eGCjqhzBJ vlPQ== MIME-Version: 1.0 Received: by 10.112.87.164 with SMTP id az4mr1498983lbb.73.1346979075081; Thu, 06 Sep 2012 17:51:15 -0700 (PDT) Received: by 10.112.95.47 with HTTP; Thu, 6 Sep 2012 17:51:14 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Sep 2012 20:51:14 -0400 Message-ID: Subject: Re: dropping revision records From: Tim Tisdall To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org Okay. I think I saw somewhere that the default was 1000. I had only about 6 revisions on each doc so changing it even to something as low as 10 wouldn't help at all, correct? -Tim On Thu, Sep 6, 2012 at 7:41 PM, Paul Davis wr= ote: > Its a PUT to /dbname/_revs_limit IIRC. Not sure if there's a wiki page or= not. > > Also, it limits the number of _revisions per leaf in a revision tree. > There's a lot of subtlety in there so you'll definitely want to fully > understand revision trees and conflict resolution before you start > going too small on that. > > On Thu, Sep 6, 2012 at 4:30 PM, Tim Tisdall wrote: >> Are there docs in the wiki on how _rev_limit works? I tried looking >> for documentation with Google, but couldn't find any. Where exactly >> is that set, and does that affect the total number of revisions across >> the database or the total per document? >> >> On Thu, Sep 6, 2012 at 4:35 PM, Robert Newson wrote= : >>> >>> 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! >>>>> >>>>> 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. >>>> >>>> It would break more than the replication. Compacting your database is >>>> the solution. >>>> >>>> - beno=EEt >>>