Original discussion: #601

Benchmark script and full outputs: https://gist.github.com/peakji/0fd6c1529951767697480e708806ae33

The benchmark script records time usage of each epoch. And an epoch comes with two flavors: sequential and parallel.

In sequential mode, we first insert some pseudo-random keys (deterministic) with a batch, then scan the keys using an iterator. In parallel mode we insert and scan at the same time, and of course unlike the sequential mode, the randomness makes the program uncertain / nondeterministic.

Between epochs, we do not clear the database.

Result shows that ending on GC is slower than ending eagerly on a busy server with mixed workload. I guess the main cause is that holding snapshots might affect compaction of new keys after the SequenceNumber.