SERVER-132235 added cursor reuse for container operations in oplog application via the getCursor lambda at src/mongo/db/repl/oplog.cpp:3303-3319, which caches one KVEngineDirectCrudCursor and re-creates it only when the ident or the sampled blind-write policy changes. Because the cache lives inside a single applyContainerOperations call, the benefit is bounded by the span of operations passed in.

Only the OplogApplierImpl batch path benefits across entries. That path groups consecutive container ops sharing nss + ident + versionContext + timestamp in groupAndApplyContainerOps (oplog_applier_utils.cpp:613-655) and passes the whole group. The other three callers pass a span of 1, so they re-acquire the cursor for every entry:

• applyOplogEntryOrGroupedInserts single-op fallback – oplog_applier_utils.cpp:571-578
• applyOps command – apply_ops.cpp:128
• prepared-transaction apply – transaction_oplog_application.cpp:179-184

We should extend cursor reuse across entries for these paths, or hoist the cursor cache to a scope that outlives a single applyContainerOperations call.

Additionally, the blind-write policy is re-sampled on every getCursor(ident) call (oplog.cpp:3313), so with gWiredTigerBlindWriteRatio < 1 the cursor is discarded and reopened mid-group even on the batch path that SERVER-132235 optimized. We should confirm whether that is intended.

Note that SERVER-131721 observes many single-key top-level ci oplog entries during the scan phase of an index build. While those persist, the single-op fallback path is hotter than the design intends, which raises the value of this work.