[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:
Related
is related to SERVER-10144 check if our semantics on getlasterro... Closed
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: SERVER-10037: move reset first
Branch: master
https://github.com/mongodb/mongo/commit/08439d7693f2c005dd2013eb482526706fb49b7f

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: SERVER-10037 Optimize updates when document is unchanged

Signed-off-by: Matt Kangas <matt.kangas@10gen.com>
Branch: master
https://github.com/mongodb/mongo/commit/9c222f4ffb1eac72d54b8c1237c8816b115af43b

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.

Generated at Thu Feb 08 03:22:05 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.