EungsopYoo commented on code in PR #8360:
URL: https://github.com/apache/hbase/pull/8360#discussion_r3431991631
##########
hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FuzzyRowFilter.java:
##########
@@ -216,9 +216,14 @@ public ReturnCode filterCell(final Cell c) {
return ReturnCode.INCLUDE;
}
}
- // NOT FOUND -> seek next using hint
+ // NOT FOUND -> seek next using hint or skip the current row.
lastFoundIndex = -1;
filterRow = true;
+ // For reverse scans, a non-matching row can recreate itself as the next
hint. Since fuzzy
+ // matching is row-key based, skip the whole non-matching row instead of
seeking to it again.
+ if (isReversed() && tracker.updateTracker(c) &&
tracker.isNextRowSameAs(c)) {
+ return ReturnCode.NEXT_ROW;
+ }
return ReturnCode.SEEK_NEXT_USING_HINT;
Review Comment:
I checked this path again. The duplicate `updateTracker` call can add
unnecessary work, but I am keeping the current structure because
`getNextCellHint` can still be called independently of `filterCell` for
seek-hint handling. Moving the update only to `filterCell` would make
`getNextCellHint` depend on that preceding call sequence.
The progress guard in `updateTracker` is still needed: it lets
`updateTracker` return when a reverse fuzzy rule recreates the current row, so
`filterCell` can return `NEXT_ROW`. Without that guard, the method can stay in
the poll/add loop before `filterCell` gets a chance to skip the row.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
