[SERVER-36631] Have the storage engine interface expose a reduced cache footprint read API Created: 14/Aug/18 Updated: 29/Oct/23 Resolved: 25/Sep/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.4 |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Daniel Gottlieb (Inactive) | Assignee: | Louis Williams |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | nyc | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Sprint: | Storage NYC 2018-10-08 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
WT is exposing a cursor configuration such that an application can communicate it's intending to read the data only once. Given that knowledge, WT will change its caching behavior of data paged in via that cursor. The expected use-case is for this behavior is when MongoDB knows a client is performing a table scan for initial sync. It may also be useful for oplog reads when the reader is behind and has to start reading a large amount of data. It's not expected that the storage glue layer will have enough information to know when opening a cursor whether it should opt-in to this behavior. This ticket is to expose a public API in the storage layer to allow higher levels declare their "read once" cases. |
| Comments |
| Comment by Githook User [ 25/Sep/18 ] |
|
Author: {'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com', 'username': 'louiswilliams'}Message: |