[
https://issues.apache.org/jira/browse/HBASE-15554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15277932#comment-15277932
]
ramkrishna.s.vasudevan commented on HBASE-15554:
------------------------------------------------
A simple way to solve is - can we here then go ahead in storing the Cf also in
the bloom key instead of making it as zero length value. Once we do that then
we have a soln to avoid all these copies in case of ROW or ROW_COL and be sure
that we deal things with zero copy. I think it should be okie. Only concern is
that with this patch in place when using a scanner on an existing HFile then
the logic of checking bloom may fail how ever once the files are major
compacted even that problem can be avoided. Will post a patch soon.
> StoreFile$Writer.appendGeneralBloomFilter generates extra KV
> ------------------------------------------------------------
>
> Key: HBASE-15554
> URL: https://issues.apache.org/jira/browse/HBASE-15554
> Project: HBase
> Issue Type: Sub-task
> Components: Performance
> Reporter: Vladimir Rodionov
> Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-15554.patch
>
>
> Accounts for 10% memory allocation in compaction thread when BloomFilterType
> is ROWCOL.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
