|
We can probably squeeze something further out of batch deletions, as some constraints can be relaxed for the pre-images and change collections. Some tuning to explore:
- Disable targetBatchTimeMS (default: 5ms) in order to bundle more documents into a batch. The main goal of this parameter is to limit the amount of pinned dirty data during a batch. This is also indirectly controlled by targetStagedDocBytes, although targetBatchTimeMS is an extra guard-rail for collections many secondary indexes, which does not apply to pre-images and change collection.
- Introduce a new BatchedDeleteStageParams entry that controls whether we should refetch a document staged for deletion if its snapshot has gone stale. Essentially, this parameter will determine whether to skip a call to ensureStillMatchesAndUpdateStats(). This refetch ensures that a document that was staged for deletion is still eligible for deletion when committing the batch. Refetching can be expensive, and becomes more likely as the batch size increases. Refetching only applies to collections with concurrent deletes or updates; this doesn't apply to pre-images and change collections.
- All the above should help avoid most of the overhead due to refetching documents, and we should be able to increase the targetBatchDocs to a value that could be even higher than the 32 proposed in this ticket.
|