[
https://issues.apache.org/jira/browse/HBASE-14920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15280216#comment-15280216
]
Edward Bortnikov commented on HBASE-14920:
------------------------------------------
[anoop.hbase], you have a point. The whole space of when/how much to flush, in
memory/to disk is yet to be explored and optimized. It seems though that some
aspects of it are being addressed in the HBASE-14921 discussion. For example,
we already accepted your suggestion to decide selectively, upon flush, whether
to compact multiple in memory segments or just flatten the newest segment.
Other optimizations can be optimized as part of the same conversation.
Unless there is some critical flaw with the baseline functionality in this
jira, I'd suggest to finalize it, and defer the performance discussions to the
next jira. It's already a lot of code. A commit would expedite the ensuing work
a lot. Not avoiding the discussion but just trying to be realistic .. Does this
makes sense?
> Compacting Memstore
> -------------------
>
> Key: HBASE-14920
> URL: https://issues.apache.org/jira/browse/HBASE-14920
> Project: HBase
> Issue Type: Sub-task
> Reporter: Eshcar Hillel
> Assignee: Eshcar Hillel
> Attachments: HBASE-14920-V01.patch, HBASE-14920-V02.patch,
> HBASE-14920-V03.patch, HBASE-14920-V04.patch, HBASE-14920-V05.patch,
> HBASE-14920-V06.patch, HBASE-14920-V07.patch, HBASE-14920-V08.patch,
> move.to.junit4.patch
>
>
> Implementation of a new compacting memstore with non-optimized immutable
> segment representation
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
