-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
db_bench: new benchmark - seek to deleted ranges #200
Labels
Milestone
Comments
Yuval-Ariel
added a commit
that referenced
this issue
Nov 14, 2022
Yuval-Ariel
added a commit
that referenced
this issue
Nov 14, 2022
Yuval-Ariel
added a commit
that referenced
this issue
Nov 14, 2022
Yuval-Ariel
added a commit
that referenced
this issue
Nov 15, 2022
Yuval-Ariel
added a commit
that referenced
this issue
Nov 23, 2022
Yuval-Ariel
added a commit
that referenced
this issue
Nov 25, 2022
Closed
Yuval-Ariel
added a commit
that referenced
this issue
Apr 30, 2023
Yuval-Ariel
added a commit
that referenced
this issue
May 4, 2023
udi-speedb
pushed a commit
that referenced
this issue
Nov 13, 2023
udi-speedb
pushed a commit
that referenced
this issue
Nov 15, 2023
udi-speedb
pushed a commit
that referenced
this issue
Dec 3, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Owner: yuval
We need to test the performance when the user does delete of large range of keys (one after the other) and than calls seek to the first element in this range.
The test is:
create N ranges where each range is M long. - hash the prefix of each range so as not to be sequential in db. the range itself is sequential.
then start deleting the ranges while simultaneously adding more ranges (same ranges as before). do this in the same thread, delete a whole range, then write a new range.
after deleting K ranges, start seeking to the beginning of the deleted ranges and time it. while still creating and deleting ranges.
The text was updated successfully, but these errors were encountered: