[SERVER-5725] streamline cursor advancement on write Created: 30/Apr/12  Updated: 10/Dec/14  Resolved: 14/Jan/14

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Aaron Staple Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-4154 Delete code doesn't correctly advance... Closed
is related to SERVER-5198 incorrect assumptions in write operat... Closed
Participants:

 Description   

1) Indexed cursors need not be considered in ClientCursor::aboutToDelete(). Indexed cursors recover their position in recoverFromYield() so advancement on document deletion is unnecessary. Currently, matching indexed cursors are prepared for and recover from yielding at each deletion advancement, which may cause a substantive performance penalty in some cases due to unnecessary btree lookups. Indexed cursors currently recover their positions after key modifying document updates, which do not trigger ClientCursor::aboutToDelete() or other explicit advancements. This means indexed cursors should already correctly handle a key deletion triggered by a document deletion. At this time indexed ClientCursors should continue to maintain valid refLoc() values if changes to one of the btree bucket invalidation implementations are to be avoided (see SERVER-4575).

2) Cursor based write operations (update and delete) currently (with the SERVER-5198 fix) advance to a document other than the one to be modified before performing a modification. This could potentially result in a significant number of iterations through adjacent keys being performed without yielding, which in the update case may be particularly significant because with delete the keys will all be removed without yielding while with update they may not be. The following alternative implementation may be used: If the cursor is unindexed, advance it to the next iterate; otherwise do not advance before modification. This implementation will handle $or clause transitions properly, and indexed cursors will be handled properly by recoverFromTouchingEarlierIterate(). This alternative implementation requires more (currently correct) assumptions than the current one, for example that a $or query will not traverse another cursor after an unindexed cursor. While more efficient in some cases, the implementation would be a bit more delicate.



 Comments   
Comment by Eliot Horowitz (Inactive) [ 14/Jan/14 ]

The code in question has been completely replaced.

Comment by auto [ 13/May/12 ]

Author:

{u'login': u'astaple', u'name': u'Aaron', u'email': u'aaron@10gen.com'}

Message: SERVER-5725 Mark relevant code points.
Branch: master
https://github.com/mongodb/mongo/commit/39cee2f29437364f2f53cd7673ff373a74b781cf

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