scanSegments

An ordered walk over the documents in [from, to] held by the named segments only.

The partial half of a query plan: an index answers for the segments it covers, and this reads the ones it does not. Where scan reads every source the view pinned, this reads the ones asked for, plus the memtables unless includeUnflushed says otherwise.

What it yields is a candidate, not necessarily the version snapshot sees, and that is the whole of its contract. Versions are collapsed within the named sources, so a key whose newest visible version lives in a segment that was not named — or in a memtable, when includeUnflushed is false — is reported here carrying an older document, or suppressed behind a tombstone that a newer write has already undone, or not reported at all. A caller must re-resolve each key through get against the same snapshot unless it can show that the named sources are the whole of what that key could be in. That is the rule an index hit already obeys, arrived at from the other side.

Segment numbers snapshot's version does not hold are ignored, and that is not leniency: the live set moves under a long-lived snapshot, so a caller working from a set it obtained elsewhere will legitimately name a compaction output this view never had. Anything such a segment holds is either invisible at this sequence or still reachable through the sources this view does pin. Snapshot.segmentNumbers is the set that is actually here.

The snapshot is required, where scan takes one optionally. A set of segment numbers only means something relative to a pinned version, and taking one internally would let a caller name segments from a version they never saw.