[
https://issues.apache.org/jira/browse/HBASE-16444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15430077#comment-15430077
]
ramkrishna.s.vasudevan commented on HBASE-16444:
------------------------------------------------
bq. So when we have non KV cells, this will make key heap size bigger. So what
way it will impact? (Good or bad way)
Am not changing the key 'heap' size. It is the actual key size that we are
going to write. What ever may be the cell type this is the key size we will be
writing. Am not sure why it was not done uniformly. 'Heap' size I agree but
actual key size should be same as far as our key structure is going to be same.
> CellUtil#getSumOfCellKeyElementLengths() should consider
> KEY_INFRASTRUCTURE_SIZE
> --------------------------------------------------------------------------------
>
> Key: HBASE-16444
> URL: https://issues.apache.org/jira/browse/HBASE-16444
> Project: HBase
> Issue Type: Bug
> Reporter: ramkrishna.s.vasudevan
> Assignee: ramkrishna.s.vasudevan
> Priority: Minor
> Attachments: HBASE-16444.patch
>
>
> Currently CellUtil#getSumOfCellKeyElementLengths() considers
> {code}
> return cell.getRowLength() + cell.getFamilyLength() +
> cell.getQualifierLength() +
> KeyValue.TIMESTAMP_TYPE_SIZE;
> {code}
> It can consider the 2 byte ROWLEN and 1 byte FAMILY_LEN also because with the
> current way of things we are sure how our key is structured.
> But pls note that
> {code}
> // This will be a low estimate. Will do for now.
> return getSumOfCellKeyElementLengths(cell);
> {code}
> It says clearly it is going to be a low estimate. But in the write path there
> should be no harm in adding the complete KEY_INFRA_SIZE.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
