jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Parvulescu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-4293) Refactor / rework compaction gain estimation
Date Tue, 09 Aug 2016 13:07:20 GMT

    [ https://issues.apache.org/jira/browse/OAK-4293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15413482#comment-15413482
] 

Alex Parvulescu commented on OAK-4293:
--------------------------------------

bq. OTOH, I'm not too happy with the record id in the gc journal as its semantics seem vague
to me. Maybe replace it with the record id that resulted from compaction!?
yeah, that felt awkward from the beginning. I was actually wondering if a pair of (timestamp,
size) would suffice. not even sure having the record id helps in any way so I'm leaning heavily
towards dropping it entirely.

> Refactor / rework compaction gain estimation 
> ---------------------------------------------
>
>                 Key: OAK-4293
>                 URL: https://issues.apache.org/jira/browse/OAK-4293
>             Project: Jackrabbit Oak
>          Issue Type: Task
>          Components: segment-tar
>            Reporter: Michael Dürig
>            Assignee: Alex Parvulescu
>              Labels: gc
>             Fix For: Segment Tar 0.0.10
>
>         Attachments: OAK-4293-v2.patch, size-estimation.patch
>
>
> I think we have to take another look at {{CompactionGainEstimate}} and see whether we
can up with a more efficient way to estimate the compaction gain. The current implementation
is expensive wrt. IO, CPU and cache coherence. If we want to keep an estimation step we need
IMO come up with a cheap way (at least 2 orders of magnitude cheaper than compaction). Otherwise
I would actually propose to remove the current estimation approach entirely 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message