[ https://issues.apache.org/jira/browse/HBASE-2265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12885353#action_12885353 ]
HBase Review Board commented on HBASE-2265: ------------------------------------------- Message from: "Kannan Muthukkaruppan" <kan...@facebook.com> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://review.hbase.org/r/257/#review302 ----------------------------------------------------------- trunk/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java <http://review.hbase.org/r/257/#comment1351> I am not clear on this scan.getStartRow() stuff. Note: This is not new with your change. You have only moved the getStartRow() call to instead shouldSeek(). Question applies more to the bloom filter logic I think. It doesn't seem safe to make a decision to seek into a file or not based just on the startRow(). This only seems safe for a Get (which is implemented as a scan with the same row being the start & stop row). - Kannan > HFile and Memstore should maintain minimum and maximum timestamps > ----------------------------------------------------------------- > > Key: HBASE-2265 > URL: https://issues.apache.org/jira/browse/HBASE-2265 > Project: HBase > Issue Type: Improvement > Components: regionserver > Reporter: Todd Lipcon > Assignee: Pranav Khaitan > > In order to fix HBASE-1485 and HBASE-29, it would be very helpful to have > HFile and Memstore track their maximum and minimum timestamps. This has the > following nice properties: > - for a straight Get, if an entry has been already been found with timestamp > X, and X >= HFile.maxTimestamp, the HFile doesn't need to be checked. Thus, > the current fast behavior of get can be maintained for those who use strictly > increasing timestamps, but "correct" behavior for those who sometimes write > out-of-order. > - for a scan, the "latest timestamp" of the storage can be used to decide > which cell wins, even if the timestamp of the cells is equal. In essence, > rather than comparing timestamps, instead you are able to compare tuples of > (row timestamp, storage.max_timestamp) > - in general, min_timestamp(storage A) >= max_timestamp(storage B) if storage > A was flushed after storage B. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.