Fix the SegmentKey formatting such that the biggest most recent segment is always returned first
The SegmentKey starts with the inverted end-frame-no such that all segments are ordered by reverse biggest frame_no, then comes the start_frame no, in natural order, so that, for the same end_frame_no, the one with the smallest frame_no is ordered first. Lastly is the segment timestamp, which is roughly the commit time of the last txn in the segment. On merge, this is inheritted from the most recent segment, and the timestamp is therefore never a tie-breaker.
This change of key scheme means that we can't easily find segment by frame_no like we did before, but that's actually ok: we never need to fetch a random frame_no, rather, we iterate backward from segment boundary to segment boundary. This new key scheme let's us do that by letting us find the next segment whose end frame_no is less than or equal to the some value, which is what we actually need. Fetching a segment with a end_frame_no less than u64::MAX will always return the biggest segment with the most recent end_frame_no.
All these changes force means that we need to refactor for semantics, but the usage remains unchanged.
Fix the SegmentKey formatting such that the biggest most recent segment is always returned first
The
SegmentKeystarts with the inverted end-frame-no such that all segments are ordered by reverse biggest frame_no, then comes the start_frame no, in natural order, so that, for the same end_frame_no, the one with the smallest frame_no is ordered first. Lastly is the segment timestamp, which is roughly the commit time of the last txn in the segment. On merge, this is inheritted from the most recent segment, and the timestamp is therefore never a tie-breaker.This change of key scheme means that we can't easily find segment by frame_no like we did before, but that's actually ok: we never need to fetch a random frame_no, rather, we iterate backward from segment boundary to segment boundary. This new key scheme let's us do that by letting us find the next segment whose end frame_no is less than or equal to the some value, which is what we actually need. Fetching a segment with a end_frame_no less than u64::MAX will always return the biggest segment with the most recent end_frame_no.
All these changes force means that we need to refactor for semantics, but the usage remains unchanged.