stack commented on HBASE-16608:

[~devaraj] User-facing doc is a TODO (Could file a JIRA @anasta ? Premature up 
to this but it is now coming time). Intent is that this facility is just on and 
beneficial with nought for the user to do. Otherwise we'll leave it off. 
Pending perf analysis.

On your concern that this be done in a branch, this work was started a long 
time ago when hbase 2.0 was far off. It has gone on longer than any of us 
expected .  Inmemory compaction has a large overlap with the offheaping work of 
Ram and Anoop. Master branch seemed the best place to coordinate the two 
efforts. I think a branch makes more sense when a focused team is working on a 
standalone feature. But I appreciate your concern with 2.0.0 coming up fast.

As DD says, it is tough having to cover multiple JIRAs with loads of 
attachments to try and get a sense of the current state of development. In the 
past -- Ram, you've done this with respect to  offheaping read path IIRC -- a 
summary of current state by one of the parties involved has helped community 
grok where we are. Maybe I could do it. I just got my perf cluster back and 
could take the current state for a spin and report back what I'm seeing?

> Introducing the ability to merge ImmutableSegments without copy-compaction or 
> SQM usage
> ---------------------------------------------------------------------------------------
>                 Key: HBASE-16608
>                 URL: https://issues.apache.org/jira/browse/HBASE-16608
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Anastasia Braginsky
>            Assignee: Anastasia Braginsky
>         Attachments: HBASE-16417-V02.patch, HBASE-16417-V04.patch, 
> HBASE-16417-V06.patch, HBASE-16417-V07.patch, HBASE-16417-V08.patch, 
> HBASE-16417-V10.patch, HBASE-16608-V01.patch, HBASE-16608-V03.patch, 
> HBASE-16608-V04.patch, HBASE-16608-V08.patch

This message was sent by Atlassian JIRA

Reply via email to