You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Jingcheng Du (JIRA)" <ji...@apache.org> on 2016/07/20 03:02:20 UTC

[jira] [Comment Edited] (HBASE-16225) Refactor ScanQueryMatcher

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

Jingcheng Du edited comment on HBASE-16225 at 7/20/16 3:01 AM:
---------------------------------------------------------------

Thanks [~stack]. I read HBASE-9440 and realized that I misunderstood the purpose.
My purpose is to reduce the number of StoreFileScanners in the heap which might reduce the comparing in scan, and only add the StoreFileScanners into the heap when they are needed.


was (Author: jingcheng.du@intel.com):
Thanks [~stack]. I read HBASE-9440 and realized that I misunderstood the purpose.
My purpose is to reduce the number of StoreFileScanners in the heap which might reduce the preparing in scan, and only add the StoreFileScanners into the heap when they are needed.

> Refactor ScanQueryMatcher
> -------------------------
>
>                 Key: HBASE-16225
>                 URL: https://issues.apache.org/jira/browse/HBASE-16225
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Duo Zhang
>
> As said in HBASE-16223, the code of {{ScanQueryMatcher}} is too complicated. I suggest that we can abstract an interface and implement several sub classes which separate different logic into different implementations. For example, the requirements of compaction and user scan are different, now we also need to consider the logic of user scan even if we only want to add a logic for compaction. And at least, the raw scan does not need a query matcher... we can implement a dummy query matcher for it.
> Suggestions are welcomed. Thanks.



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