hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ramkrishna.s.vasudevan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-16501) seekToPrevoiusRow() can be optimized
Date Thu, 01 Sep 2016 10:17:21 GMT

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

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

Also HBASE-15871 is much more involved. But this is simple and straight forward. When I raised
this JIRA i was not aware of that but only after I solved the problem and investigated then
found that already it is trying to solve nextRow case but only in such unique cases of readpt
being lesser than all the cells this problem occurs. 
Infact in StorefileScanner this issue is not there since we do get a cell before we decide
if to skip or not. Hence did not apply the fix to Storefilescanner.

> 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)

Mime
View raw message