[
https://issues.apache.org/jira/browse/HBASE-18056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16018956#comment-16018956
]
Edward Bortnikov commented on HBASE-18056:
------------------------------------------
Friends,
I'm having a hard time understanding why this commit became a big deal :) We
made a mistake. This parameter change should have been committed together with
BASIC compaction becoming the default configuration. BASIC does not make sense
without it. We presented a vey extensive perf evaluation exactly with this
parameter value. It demonstrated improvement in all the operational metrics, GC
included. The parameter should be not accessible to users; it is not documented
in the reference manual; its sole purpose is developer flexibility.
It is perfectly okay to re-open the discussion (and also revert the setting)
once there is solid proof that something is broken. But we didn't see any such
proof yet. Delaying without reason jeopardizes the feature, especially in
anticipation of release.
Just saying it again - we made a technical mistake, and we are fixing it now.
There is no new data.
What is it that I get wrong? Thanks.
> Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline
> ------------------------------------------------------------------------------
>
> Key: HBASE-18056
> URL: https://issues.apache.org/jira/browse/HBASE-18056
> Project: HBase
> Issue Type: Sub-task
> Reporter: Anastasia Braginsky
> Attachments: HBASE-18056-V01.patch
>
>
> Under HBASE-16417 it was decided that CompactingMemStore in BASIC mode should
> merge multiple ImmutableSegments in CompactionPipeline. Basic+Merge actually
> demonstrated reduction in GC, alongside improvement in other metrics.
> However, the limit on the number of segments in pipeline is still set to 30.
> Under this JIRA it should be changed to 1, as it was tested under HBASE-16417.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
