storage: add scan benchmark with resolved intents and fix pebbleMVCCS… #96380
Conversation
|
This change is |
…canner.itersBeforeSeek This commit restores the lower-bound of 1 on pebbleMVCCScanner.itersBeforeSeek. This has no effect on the added benchmark since on master (unlike v22.2) we use Pebble's Iterator.NextPrefix for the common case of stepping to the next roachpb.Key. itersBeforeSeek continues to be used for seeking to a particular version and for reverse scans. The added benchmark has 7 levels and resolved intents where both the Set and SingleDelete of the intent are present in Pebble. It tries to trick pebbleMVCCScanner with having keys with many versions in the beginning of the scan. Benchmark results: BenchmarkMVCCScannerWithIntentsAndVersions-10 4000 316177 ns/op 133119 B/op 28 allocs/op stats: (interface (dir, seek, step): (fwd, 2, 1999), (rev, 0, 0)), (internal (dir, seek, step): (fwd, 2, 3110), (rev, 0, 0)), (internal-stats: (block-bytes: (total 15 K, cached 15 K)), (points: (count 3.1 K, key-bytes 88 K, value-bytes 60 K, tombstoned 0))) Informs cockroachdb#96361 Epic: none Release note: None
sumeerbhola
force-pushed
the
scanner_bench
branch
from
90a7429 to
6f01e09
Compare
There was a problem hiding this comment.
Reviewed 1 of 2 files at r1, 1 of 1 files at r2, all commit messages.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @jbowens and @sumeerbhola)
-- commits line 16 at r2:
These numbers are hard to gauge as good / bad. Any comparison / delta worth putting in here? Or are we simply establishing a baseline?
pkg/storage/bench_test.go line 1930 at r2 (raw file):
sstFile, err := eng.Create(sstFileName) require.NoError(b, err) // No improvement with v3 since the multiple versions are in different
At some point wont all files be v3? Is there any harm in using that version here? Or even just the "latest" / "newest" version?
|
Flakes in backupccl :( |
There was a problem hiding this comment.
TFTR!
Reviewable status:
Previously, nicktrav (Nick Travers) wrote…
These numbers are hard to gauge as good / bad. Any comparison / delta worth putting in here? Or are we simply establishing a baseline?
Don't have a delta. This is slightly faster than v22.1, which came in ~350000 ns/op.
pkg/storage/bench_test.go line 1930 at r2 (raw file):
Previously, nicktrav (Nick Travers) wrote…
At some point wont all files be
v3? Is there any harm in using that version here? Or even just the "latest" / "newest" version?
It may not be the default for v23.1. Eventually we'll want to test with both.
|
bors r+ |
|
Build succeeded: |
…canner.itersBeforeSeek
This commit restores the lower-bound of 1 on
pebbleMVCCScanner.itersBeforeSeek. This has no effect on the added benchmark since on master (unlike v22.2) we use Pebble's Iterator.NextPrefix for the common case of stepping to the next roachpb.Key. itersBeforeSeek continues to be used for seeking to a particular version and for reverse scans.
The added benchmark has 7 levels and resolved intents where both the Set and SingleDelete of the intent are present in Pebble. It tries to trick pebbleMVCCScanner with having keys with many versions in the beginning of the scan. Benchmark results:
Informs #96361
Epic: none
Release note: None