[ryanworl]

Reading a million individual keys would be quite rare I would guess, but that isn’t really the issue for a large range. The keys at the start and the end of the range are what’s counted in that case. So if you read the range A-Z, the size is only those two keys A and Z, not the size of keys in between.

More relevant for the current storage engines (although changing in a future storage engine from digging through the code and the abstract for an upcoming talk) is the five second transaction duration limit. That’s just because the multi-version data structure only includes the last 5s of versions.

[realreality]

Oh, that’s even less-expected behavior! In that case, one would never run into the size limitation for range reads. I think the docs should clarify that only the first and last keys count toward the transaction size.

Yes, the 5 second limit could be a problem.

[ryanworl]

There are two reasons for this I can see:

1) All mutations and key ranges are stored locally and submitted when the transaction commits. Lots of data to transfer.

2) the optimistic conflict checker can process one range (even if it is a lot of underlying keys) a lot easier than each individual key in that range