Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 21 Oct 2014 05:34:34 +0000 (UTC)
From: "Lars Hofhansl (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12749421.1413863345000.303158.1413869674729@Atlassian.JIRA>
In-Reply-To: <JIRA.12749421.1413863345000@Atlassian.JIRA>
References: <JIRA.12749421.1413863345000@Atlassian.JIRA>
 <JIRA.12749421.1413863345509@arcas>
Subject: [jira] [Updated] (HBASE-12303) Seek to next row after family delete
 markers
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HBASE-12303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lars Hofhansl updated HBASE-12303:
----------------------------------
    Resolution: Invalid
        Status: Resolved  (was: Patch Available)

Nah. The FAMILY_DELETE marker does not effect columns with a newer timestamp, so we can't rule out that there are newer columns not effected by this delete marker, we need to check them one-by-one.

Meh.


> Seek to next row after family delete markers
> --------------------------------------------
>
>                 Key: HBASE-12303
>                 URL: https://issues.apache.org/jira/browse/HBASE-12303
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Lars Hofhansl
>         Attachments: 12303.txt
>
>
> Currently we seek to the next column when we encounter a family delete marker.
> I think we safely seek the current store to next row.
> We ran into a scenario with very slow scans after a lot of rows have been deleted with family delete markers. Some profiling revealed that we seek for once for each row and column.
> This won't make this go away entirely, but at least we can seek once per row rather than once per column.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)