While working on
OPENDJ-3896, I noticed that the changelog cursors are still performing far too many IO to read records/position themselves.
This bug is a follow-up of
- A subsequent refactoring for
undid the performance improvements. See how readRecordAtPosition() calls readCurrentRecord(): lastBlockStartPosition field is set to remember which record was read, but it is then overwritten by the next call to -1 by the call to readCurrentRecord() immediately following. OPENDJ-2218
- seekToRecord() calls searchClosestBlockStartToKey() which tries to find the closest block start to key. This methods performs repeated I/O reads via repeated calls to readRecordAtPosition() method.
It does so without taking into consideration the key matching strategy, which can be wasteful. For example, when the key matching strategy is GREATER_THAN_OR_EQUAL_TO_KEY, and the key comparison is negative (middleRecord.getKey().compareTo(key) < 0), then the algorithm can stop immediately. Vice-versa with the LESS_THAN_OR_EQUAL_TO_KEY key matching strategy, and middleRecord.getKey().compareTo(key) > 0.