[SERVER-12224] Allow an explicit padding (or total size) to be specified when inserting new documents Created: 31/Dec/13 Updated: 06/Dec/22 Resolved: 14/Sep/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | MMAPv1, Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Jason R. Coombs | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Won't Fix | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Storage Execution
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
While the automatic padding factor is a good first-order approximation for determining data growth, it's not adequate for some stores in which the application can know in advance how large a document might grow to and in which growth has serious performance implications. In this case, MongoDB suggests adding manual padding. It would be nice if MongoDB supported this explicit padding naturally as part of the insert query. The insert (and probably upsert and save) operations would be extended with a 'padding_bytes' and/or a 'min_allocation_bytes' parameter (or similar) such that the insert operation would allocate a minimum amount of space for that document. For example::
It appears that currently the insert operation doesn't accept any optional parameters, so this change would require extending that signature or otherwise providing such a mechanism. The advantages of this technique over the prescribed technique are clear: 1) Only one round trip to save the document. |