[SERVER-12231] explain() for GeoSearchCursor broken Created: 02/Jan/14  Updated: 11/Jul/16  Resolved: 05/Feb/14

Status: Closed
Project: Core Server
Component/s: Geo
Affects Version/s: 2.4.8, 2.5.4
Fix Version/s: 2.6.0-rc0

Type: Bug Priority: Major - P3
Reporter: Thomas Rueckstiess Assignee: Benety Goh
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File gscexplain.js    
Issue Links:
Duplicate
is duplicated by SERVER-9222 On explain() millis value is 0 for Ge... Closed
is duplicated by SERVER-12229 geoNear results has incorrect nscanned Closed
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

All these examples below require a dataset and index, which can be created with the attached gscexplain.js file.

Participants:
Linked BF Score: 0

 Description   

I found several problems with the explain() output for GeoSearchCursors.

Table Of Contents
  1. In versions 2.4.8 and below, the millis value of a GeoSearchCursor from a 2d index is always 0
  2. Version 2.5.4 returns different numbers than version 2.4.8 for nscanned, nscannedObjects, etc.
  3. The nscanned value does not show the actual number of scanned documents
  4. The index name is not shown for GeoSearchCursor
1. millis always 0

In versions 2.4.8 and below, the millis value of a GeoSearchCursor from a 2d index is always 0

This find took 2.5 seconds, but millis returns 0

> var t = new ISODate(); printjson(db.gscexplain.find({loc: {$near: [40, 40]}, _id: {$lt: 50}}).explain()); print(new ISODate() - t);
{
    "cursor" : "GeoSearchCursor",
    "isMultiKey" : false,
    "n" : 50,
    "nscannedObjects" : 50,
    "nscanned" : 50,
    "nscannedObjectsAllPlans" : 50,
    "nscannedAllPlans" : 50,
    "scanAndOrder" : false,
    "indexOnly" : false,
    "nYields" : 0,
    "nChunkSkips" : 0,
    "millis" : 0,
    "indexBounds" : {
 
    },
    "server" : "enter.local:27017"
}
2517

In version 2.5.4, the millis display seems to be fixed (however, now it takes 1 second longer, but that's another issue).

> var t = new ISODate(); printjson(db.gscexplain.find({loc: {$near: [40, 40]}, _id: {$lt: 50}}).explain()); print(new ISODate() - t);
{
    "cursor" : "GeoSearchCursor",
    "isMultiKey" : false,
    "n" : 50,
    "nscannedObjects" : 51,
    "nscanned" : 51,
    "nscannedObjectsAllPlans" : 51,
    "nscannedAllPlans" : 51,
    "scanAndOrder" : false,
    "indexOnly" : false,
    "nYields" : 0,
    "nChunkSkips" : 0,
    "millis" : 3545,
    "server" : "enter.local:27017"
}
3548

2. nscanned differs in 2.5.4

Version 2.5.4 returns different numbers than version 2.4.8 for nscanned, nscannedObjects, etc.

See two explain examples above. The 2.4.8 version returns nscanned:50, the 2.5.4 version returns nscanned: 51.

3. nscanned incorrect

The nscanned value does not show the actual number of scanned documents

The query

db.gscexplain.find({loc: {$near: [40, 40]} }).explain()

returned nscanned:100 (or nscanned:101 for 2.5.4).

Using the command form of the same query returns very different numbers for nscanned:

> db.runCommand({geoNear: "gscexplain", near: [40, 40] })['stats']
{
    "btreelocs" : 0,
    "maxDistance" : 0.005736338360377385,
    "avgDistance" : 0.003546263440475973,
    "objectsLoaded" : 217,
    "nscanned" : 611,
    "time" : 3
}

4. No index name

The index name is not shown for GeoSearchCursor

Other indexes state the name, for example "cursor" : "BtreeCursor a_1". The GeoSearchCursor only writes "cursor" : "GeoSearchCursor". While this may be less of an issue currently, as only one geo index is allowed per collection, we should still be consistent here for when this limitation is lifted in the future.



 Comments   
Comment by Githook User [ 05/Feb/14 ]

Author:

{u'username': u'benety', u'name': u'Benety Goh', u'email': u'benety@mongodb.com'}

Message: SERVER-12231 fixed explain for geo 2D
Branch: master
https://github.com/mongodb/mongo/commit/e3cc88909df12c1d04be02dcf95faa3d208b8ee1

Comment by Thomas Rueckstiess [ 02/Jan/14 ]

fixed small typo in the data-generating script, uploaded new version.

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