[SERVER-10037] Optimize updates when document is unchaged Created: 26/Jun/13 Updated: 11/Jul/16 Resolved: 10/Jul/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Write Ops |
| Affects Version/s: | None |
| Fix Version/s: | 2.5.1 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Ron Avnur | Assignee: | Ron Avnur |
| Resolution: | Done | Votes: | 0 |
| Labels: | idempotency, oplog | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Participants: | |||||||||
| Description |
|
In an update that replaces existing document with a new document, if the new and old documents are byte-equal (operation is a no-op), do not perform the update in oplog / journal / disk. |
| Comments |
| Comment by auto [ 15/Jul/13 ] |
|
Author: {u'username': u'scotthernandez', u'name': u'Scott Hernandez', u'email': u'scotthernandez@gmail.com'}Message: |
| Comment by Matt Kangas [ 10/Jul/13 ] |
|
Merged in 9c222f4ffb1eac72d54b8c1237c8816b115af43b after fixing compile failure. |
| Comment by auto [ 10/Jul/13 ] |
|
Author: {u'username': u'avnur', u'name': u'Ron Avnur', u'email': u'ron@10gen.com'}Message: Signed-off-by: Matt Kangas <matt.kangas@10gen.com> |
| Comment by Dwight Merriman [ 08/Jul/13 ] |
|
Note if this existing and were to fire, the savings would be huge. We already check indexes for non-mutation, so no gain there. However, a lot of code would be short circuited so there is cpu savings; and we don't write to either oplog or journal which is pretty big savings. In addition, the write to the record, that is a big savings too – even though the bytes are the same, the page will be dirty and written out. And that write is a random write I/O, which will have to be flushed in 60 seconds, so quite expensive. For a database that fits in RAM, yet is on spinning disks, it would be a huge difference. Now, of course, it only helps if the write is a no-op, and of course for many use cases that will never come into play! |
| Comment by Dwight Merriman [ 08/Jul/13 ] |
|
Imagine if an update is a no-op on the primary. In that case idempotency is not relevant? That is to say, I propose we optimize these out for primary writes, and don't do anything fancy when applying replicated statements. |
| Comment by Scott Hernandez (Inactive) [ 26/Jun/13 ] |
|
There are some problems with this as the current update will create an oplog entry, even if the doc is not updated. If your goal is to minimize IO, that is great, but changing oplog/idempotency rules is not trivial without proving they are correct. |