[ https://issues.apache.org/jira/browse/OAK-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632158#comment-15632158 ]
Michael Dürig commented on OAK-5046: ------------------------------------ My reasoning for using an absolute threshold instead of a relative one for the estimator was that e.g. on a 1GB repository a 50% increase would lead to 1.5GB. Hardy a reason to run gc. OTOH a 50% increase on a 50GB repository leads to 75GB, which should cause a gc run. But as we seem to have a hard time with coming up with a good default value, we should maybe try to tackle this from the other end: say we make it a relative value. Can we come up with a good default value then? What would it be and why? > Remove the old estimation OSGi setting (compaction.gainThreshold) > ----------------------------------------------------------------- > > Key: OAK-5046 > URL: https://issues.apache.org/jira/browse/OAK-5046 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar > Affects Versions: 1.5.12 > Reporter: Andrei Dulceanu > Assignee: Andrei Dulceanu > Priority: Minor > Labels: osgi-config > Fix For: 1.5.13 > > Attachments: OAK-5046-01.patch > > > Currently, there are two implementations for finding out the gain in > repository size after running compaction: the old one, > {{CompactionGainEstimate}} and the new one, {{SizeDeltaGcEstimation}}. > Similarly, there are also two configurations for customising them, in > {{SegmentNodeStoreService}}, {{compaction.gainThreshold}} and > {{compaction.sizeDeltaEstimation}}. > At the moment both of them are exposed as OSGi configurations, but only the > new one should be exposed (e.g. {{compaction.sizeDeltaEstimation}}). > It must be evaluated whether it makes sense to keep the logic associated with > the old implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)