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

Jingcheng Du commented on HBASE-16225:
--------------------------------------

I did a similar implementation several wekks ago [~lhofhansl].
StoreScanner only puts the necessary StoreFileScanners to the heap#1, and puts 
other StoreFileScanners to heap#2, usually StoreScanner reads cell from heap#1 
unless the top cell in heap#2 is less than heap#1, at that time StoreScanner 
puts the necessary StoreFileScanners in heap#2 back to heap#1.
Theoretically this might be useful for stripe hfiles, that in each stripe the 
hfiles have overlapped cells.
Please forgive me if I misunderstood you. Thanks.


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

Reply via email to