[SERVER-6183] count may not yield before paging in initial candidate documents Created: 22/Jun/12  Updated: 28/Jan/15  Resolved: 28/Jan/15

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

Type: Improvement Priority: Major - P3
Reporter: Aaron Staple Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: query_triage
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-8579 Consolidate Mongod Lock/Resource Sche... Closed
Participants:

 Description   

Current behavior of count is to construct a ClientCursor and perform non in mem yielding only after an elapsed tracker has elapsed. But this means it may hold a read lock while initial candidate documents are paged in.

                if ( !ccPointer ) {
                    if ( timeToStartYielding.intervalHasElapsed() ) {
                        // Lazily construct a ClientCursor, avoiding a performance regression when scanning a very
                        // small number of documents.
                        ccPointer.reset( new ClientCursor( QueryOption_NoCursorTimeout, cursor, ns ) );
                    }
                }
                else if ( !ccPointer->yieldSometimes( simpleEqualityMatch ? ClientCursor::DontNeed : ClientCursor::MaybeCovered ) ||
                         !cursor->ok() ) {
                    break;
                }

In 2.0 count did not have non in mem yielding, so current behavior does improve on that.



 Comments   
Comment by David Storch [ 28/Jan/15 ]

This ticket refers to the old query framework and does not affect the new query framework's yielding implementation. Closing as a duplicate of SERVER-10026.

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