Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Date: Thu, 18 Aug 2016 06:40:21 +0000 (UTC)
From: "ramkrishna.s.vasudevan (JIRA)" <jira@apache.org>
To: dev@hbase.apache.org
Message-ID: <JIRA.12998109.1471502384000.340656.1471502421090@Atlassian.JIRA>
In-Reply-To: <JIRA.12998109.1471502384000@Atlassian.JIRA>
References: <JIRA.12998109.1471502384000@Atlassian.JIRA> <JIRA.12998109.1471502384091@arcas>
Subject: [jira] [Created] (HBASE-16444)
 HFileWriterImpl#getSumOfCellKeyElementLengths() should consider
 KEY_INFRASTRUCTURE_SIZE
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 18 Aug 2016 06:40:25 -0000

ramkrishna.s.vasudevan created HBASE-16444:
----------------------------------------------

             Summary: HFileWriterImpl#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


Currently HFileWriterImpl#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)