-
Notifications
You must be signed in to change notification settings - Fork 428
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
db: optimize levelIter for repeated seeks with narrow and monotonic b…
…ounds Narrow bounds are common for lookup-style joins, especially index joins in CockroachDB. In a geospatial query that did an index join with 8000 spans (each of the left rows generated a span), the execution is done using a single roachpb.BatchRequest, so a single Pebble iterator is reused for the whole batch. We repeat the following 8000 times: set (narrow) bounds for the span, then iterate. When there is sufficient inter-span locality (note taht the spans are already sorted), this should look more like iteration over a single file at each level, but it currently consumes > 20% of the CPU in SeekGE. The particular query I investigated was in an under loaded Pebble, so only had data in L5 and L6 -- the L5 file was wide enough to accommodate most of the spans, but rarely had any keys within any of the spans. This PR optimizes part of the SeekGE by: - avoiding the unnecessary iteration to the next file when the iteration bound is crossed. This unnecessary iteration would cause the file to be loaded again in the next seek (levelIter.loadFile was ~5% of the cpu for the aforementioned query). - not using the synthetic boundary key when there are no range tombstones in the file (since CockroachDB uses them rarely). This reduces the number of times the mergingIter has to traverse these synthetic boundary keys before declaring itself done, since it is likely that most of the data is in the L6 file and the other levels with files are only contributing the synthetic boundary key. There are two new microbenchmarks name old time/op new time/op delta LevelIterSeqSeekGEWithBounds/restart=16/count=5-16 892ns ± 2% 661ns ± 1% -25.91% (p=0.000 n=10+8) MergingIterSeqSeekGEWithBounds/levelCount=5-16 3.68µs ±11% 1.97µs ± 2% -46.62% (p=0.000 n=10+9) Of the ~46% improvement in the mergingIter benchmark, most is due to the first change and 12% is due to the second change. The existing benchmarks are unchanged.
- Loading branch information
1 parent
d670ff5
commit a69a94e
Showing
6 changed files
with
524 additions
and
67 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.