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-16296) Reverse scan performance degrades when scanner cache size matches page filter size
Date Sat, 30 Jul 2016 03:56:20 GMT

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

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

Will this be right for SkipFilter or whileMatchFilter also?  I think this step of filterRowKey(current)
was added mainly in cases where the batch limit or size limit is reached and again we scan
for the next set of cells /rows. 
But as Lars says if filterAllRemaining also needs to be checked, then both for filterlist
and the normal filter case we should do it or for both it should not be. So may be Lars patch
makes things consistent and we can try with that? Need to see all the cases here.

> Reverse scan performance degrades when scanner cache size matches page filter size
> ----------------------------------------------------------------------------------
>
>                 Key: HBASE-16296
>                 URL: https://issues.apache.org/jira/browse/HBASE-16296
>             Project: HBase
>          Issue Type: Bug
>            Reporter: James Taylor
>         Attachments: 16296-MAYBE.txt, generatedata-snippet.java, repro-snippet.java
>
>
> When a reverse scan is done, the server seems to not know it's done when the scanner
cache size matches the number of rows in a PageFilter. See PHOENIX-3121 for how this manifests
itself. We have a standalone, pure HBase API reproducer too that I'll attach (courtesy of
[~churromorales] and [~mujtabachohan]).



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

Mime
View raw message