@@ -10,6 +10,27 @@ import "slices"
1010// mergeSpans sorts the given spans and merges ones with overlapping spans and
1111// equal access timestamps. The implementation is a modified roachpb.MergeSpans.
1212//
13+ // The input and output spans represent the same subset of {keys}x{timestamps}
14+ // space. The resulting spans are ordered by key. It is minimal (impossible to
15+ // "merge" further without losing precision) only if there are no keys present
16+ // under multiple timestamps.
17+ //
18+ // When there are keys present under multiple timestamps, the resulting merged
19+ // set is not guaranteed to be minimal. For example, [{a-b}@10, b@20, {b-c}@10]
20+ // is returned as is, even though we could merge it as [{a-c}@10, b@20]. This is
21+ // due to an arbitrary choice of sorting it by key.
22+ //
23+ // TODO(pav-kv): we could sort by (timestamp, key), which makes it possible to
24+ // merge spans with the same timestamp and guarantee minimality. After which, we
25+ // can optionally sort by key again. This is still more expensive than one sort,
26+ // so consider if the users are fine with the set sorted by (timestamp, key).
27+ //
28+ // The priority for this function is to be simple and free from assumptions
29+ // about how to "resolve" the situation of having the same key under multiple
30+ // timestamps. E.g. it does not assume that higher/lower timestamp "wins", or
31+ // what the semantics of an empty timestamp are. Considerations like that are
32+ // left to the consumer of this span set, e.g. the latch manager.
33+ //
1334// The input spans are not safe for re-use.
1435func mergeSpans (latches []Span ) []Span {
1536 if len (latches ) == 0 {
0 commit comments