[
https://issues.apache.org/jira/browse/HBASE-16417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15612299#comment-15612299
]
Anoop Sam John commented on HBASE-16417:
----------------------------------------
In memory index merge helps in scan case, I agree to ur argument. Ya am not
saying we should never do it. Ya let us experiment with diff numbers as ur
current tests. My point was that flush only tail is with the assumption that
we will merge eagerly and most of the memstore size is tail of pipeline. But
when we play with diff #segments for merge, (say 4) we will end up in much
smaller sized segment in tail and so smaller sized flush. Actually speaking
flush all is not directly related to merge. So my point is let us have such a
mechanism so that we can better test the impact of merge alone.. Now what
happens is we will avoid frequent merges (by upping the #segments for merge) so
reduce merge cost but that will have an impact on flush size. So if we can
avoid that we can test merge cost much in isolation.
bq.We just disagree on marking the opposite case (many duplicates) as special
and going down a different code path there - because if we leave it to the
admin as non-default we know what'll happen.
That is the data compaction path right? That is config driven and is in
already. you say that also u will auto tune? That will be super cool if done.
Am speaking on what is available as of today.
> In-Memory MemStore Policy for Flattening and Compactions
> --------------------------------------------------------
>
> Key: HBASE-16417
> URL: https://issues.apache.org/jira/browse/HBASE-16417
> Project: HBase
> Issue Type: Sub-task
> Reporter: Anastasia Braginsky
> Assignee: Anastasia Braginsky
> Fix For: 2.0.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
