kocolosk commented on issue #1661: _revs_limit not applied after calling _compact URL: https://github.com/apache/couchdb/issues/1661#issuecomment-431077350 Hi @tudordumitriu, I think I understand what is happening here. When you resolve a conflict in a CouchDB document the conflicted path continues to exist in the revision tree. CouchDB simply adds a `deleted:true` leaf on the end of the path. If you request one of these documents with `?meta=true` I suspect you'll see a large block of `deleted_conflicts` entries. The `_revs_limit` setting will cap the length of each individual path in the revision tree, and will then merge those shortened paths together into one or more trees. So, the number of entries in the `_revs_info` can be as high as the product of `_revs_limit` times the number of *total* paths -- deleted or otherwise. I would like to improve the behavior of the database so that it can intelligently "prune" the branches of the revision tree that track resolved conflicts once it's confident that all replication peers have observed the latest updates to the branch. It's a subtle change though with some important side effects to consider. We've also contemplated introducing user-defined conflict resolution strategies which could be more efficient than the current (maximally robust) strategy. CouchDB 1.x supported the notion of "purging" revisions entirely, which would certainly accomplish your goal of getting the revision metadata slimmed down. CouchDB 2.0 lost this capability because of some unique challenges supporting it in a cluster. We did recently re-introduce the capability in #1370 ... just after we released 2.2.0. It'll be in 2.3.0 once that's released. Net: there's not a lot you can do right now to fix up documents that had a lot of conflicts in the past. Shortening the `_revs_limit` does help -- but not as much as you think, and if it gets shortened too much you run the risk of generating additional spurious conflicts.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services