incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Number of surviving revisions after compaction
Date Mon, 20 Jan 2014 19:23:29 GMT
Slightly more precisely, _revs_limit affects the number of revisions
kept for each edit branch. While Adam's point about the replicator is
valid I don't think its quite the answer that Vladimir is looking for.

The compactor removes document bodies for each revision that is not a
leaf of the revision tree during compaction. Thus your db won't be
1000x larger than it needs to be and setting _revs_limit lower won't
save you that much on disk space.

On Mon, Jan 20, 2014 at 8:36 AM, Adam Kocoloski <> wrote:
> On Jan 20, 2014, at 11:29 AM, Vladimir Ralev <> wrote:
>> Hello all
>> I was reading about  _revs_limit
>> <>
>> which
>> defaults to 1000 or so here
>> It seems to imply that those 1000 revisions will be preserved even after
>> compaction.Is this correct and does it mean that the database will be as
>> much as 1000x bigger than it needs to be after compaction.
>> I have a database that I want to perform maintenance on so i remove it from
>> traffic and want to reduce the number of revisions to 1 again safely. Is
>> there some shortcut to do that?
> Hi, that setting controls the number of revisions about which the server keeps a record,
not the number where the actual body of the rev is preserved.  Compaction only ever preserves
the last revision of each edit branch; this is not configurable.  The _revs_limit setting
impacts replication, e.g. if you make 1001 edits on a source server in between replications
to a target the replicator will not be able to piece together edit 1 and edit 1002 and you'll
end up with a spurious conflict on the target.
> Adam

View raw message