This is a break-off ticket fromĀ WT-6796 as we want to understand why delete throughout decreases as some of the remove-only benchmarks progress.
There are few things to consider here:
- As discussed inĀ
WT-6796, the reduced delete operation doesn't seem to correlate with history store file size. - The delete throughout is decreasing as we keep deleting random documents from the test collections without replacing them.
- The benchmark is specifically testing system performance with long running transactions. From the plot above we can notice that the stat "range of timestamps currently pinned" is growing to 1 hour.
- Deleting records in WT essentially entails adding a stop timestamp the records. The actual record in not removed until the stop time becomes globally visible.
- We need to gather more information about the benchmark. For example, how cursors are being used to delete the data and if there any indexes on the test collection.
The aim of this ticket is to find the root cause behind the delete performance degradation and create tickets for possible improvements.
- is related to
-
SERVER-57221 Inconsistent delete performance on collections with multiple secondary indexes on same key
- Closed
-
WT-6796 Deleting documents takes longer when there are many updates in the history store.
- Closed
-
WT-7759 Reduce number of calls to update obsolete function
- Closed
- related to
-
WT-7757 Skip obsolete leaf pages without having to read them
- Closed