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 tisdall@gmail.com designates
 209.85.215.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <FE748315-1AEA-4211-AF0A-E01AB9C5EE9C@apache.org>
References: 
 <CAGxYWpbjfaH3Gqe_B1f_7wqEsdSDYeK3Ah5bdGgbFb-vR7yF0Q@mail.gmail.com>
	<CAJNb-9pOC-LKzp=dL=f61Ro2N2Ep_CLwfqQ-jbB7VKh4a-rTYg@mail.gmail.com>
	<FE748315-1AEA-4211-AF0A-E01AB9C5EE9C@apache.org>
Date: Thu, 6 Sep 2012 17:30:31 -0400
Message-ID: 
 <CAGxYWpaJfoEmgevi94UNeR9sGsNcX2-tUWHjj=+dKirUTFpArg@mail.gmail.com>
Subject: Re: dropping revision records
From: Tim Tisdall <tisdall@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 <rnewson@apache.org> wrote:
>
> I think Tim was clear that this was post-compaction, though. The 2gb is t=
he 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 <tisdall@gmail.com> 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
>