You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, validation is performed on a single thread by running a sequence of R/W operations (without any overlap between any of the operations), while the benchmark uses concurrent operations (but no validation is performed). This makes detecting concurrency bugs impossible. So far, this was not a serious limitation as the inserts were not too contentious and were unlikely to corrupt the database. However, with the introduction of delete operations, it will be important to perform a more thorough validation sequence.
A good middle ground would be to run a concurrent workload followed by a sequence of read-only (potentially concurrent) operations.
Technically, this seems to be relatively easy to do, as it's essentially a concatenation of a "benchmark" and a "create validation parameters" / "validate" phase.
The text was updated successfully, but these errors were encountered:
Currently, validation is performed on a single thread by running a sequence of R/W operations (without any overlap between any of the operations), while the benchmark uses concurrent operations (but no validation is performed). This makes detecting concurrency bugs impossible. So far, this was not a serious limitation as the inserts were not too contentious and were unlikely to corrupt the database. However, with the introduction of delete operations, it will be important to perform a more thorough validation sequence.
A good middle ground would be to run a concurrent workload followed by a sequence of read-only (potentially concurrent) operations.
Technically, this seems to be relatively easy to do, as it's essentially a concatenation of a "benchmark" and a "create validation parameters" / "validate" phase.
The text was updated successfully, but these errors were encountered: