Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 1 Sep 2016 08:21:20 +0000 (UTC)
From: "ramkrishna.s.vasudevan (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12999980.1472121833000.467144.1472718080542@Atlassian.JIRA>
In-Reply-To: <JIRA.12999980.1472121833000@Atlassian.JIRA>
References: <JIRA.12999980.1472121833000@Atlassian.JIRA> <JIRA.12999980.1472121833308@arcas>
Subject: [jira] [Commented] (HBASE-16501) seekToPrevoiusRow() can be
 optimized
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 01 Sep 2016 08:21:27 -0000


    [ https://issues.apache.org/jira/browse/HBASE-16501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15454737#comment-15454737 ] 

ramkrishna.s.vasudevan commented on HBASE-16501:
------------------------------------------------

Yes.
As said in my first comment
bq.the var 'stopSkippingKVsIfNextRow ' is for avoiding this unnecessary skip I think but the condition does not work when starkKV itself is null.
This does not work in this case. Anyway HBASE-15871 will help to avoid memstore scanners if the read pt is less than the last flushed seqid. Because in that case all the cells are in the file.

> seekToPrevoiusRow() can be optimized
> ------------------------------------
>
>                 Key: HBASE-16501
>                 URL: https://issues.apache.org/jira/browse/HBASE-16501
>             Project: HBase
>          Issue Type: Improvement
>          Components: Performance, Scanners
>    Affects Versions: 2.0.0
>            Reporter: ramkrishna.s.vasudevan
>            Assignee: ramkrishna.s.vasudevan
>             Fix For: 2.0.0
>
>         Attachments: HBASE-16501.patch, HBASE-16501_1.patch, HBASE-16501_sysocount.patch
>
>
> Need to check the details and see how to implement it. But the problem is this
> In seekToPReviousRow impl in case of a reverse scan, say we have rows row10000 to row20000. We are doing a reverse scan.
> The scan starts from row20000 and we read all columns. Assume this row was skipped due to mvcc we move to the previous row 'row19999'. Now we read this row19999 and even if this does not match in mvcc we skip and again read row20000 and do the same. 
> Like this we keep doing til we come to row10000 and this time we read til row20000 just to k now we have to skip it. The same problem happens in Storefilescanner also and there we do lot of seek and next(). Better to solve this case. 
> [~zjushch] - FYI.


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