Uploaded image for project: 'Documentation'
  1. Documentation
  2. DOCS-6017

Comment on: "manual/reference/operator/aggregation/geoNear.txt"



    • Type: Bug
    • Status: Open
    • Priority: Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: manual, Server
    • Labels:
    • Environment:


      This page should document how the optional "query" predicate and the geo search work together, and how it relates to indexes. From my experiments, this is how I think it works:

      a) If there is only an index on the geo field, the query predicate is an additional filter stage that may or may not be present and which is not particularly optimized.
      b) If there is a compound index on the geo field and the field(s) used by the query, then that index will be used for the $geoNear, and it will speed up the whole thing considerably. The speedup can be different depending on whether the query attributes come before the geo field or after it in the index.
      c) If the geo field is only one of several fields in a compound index, and it is not the first field in that index, then there must be a query parameter in the $geoNear and it must contain a predicate on the fields that come before the geo field in the compound index, otherwise you'll get an error message saying the query engine cannot be started.

      This should be documented.


          Issue Links



              • Assignee:
                kay.kim Kay Kim
                andre.spiegel Andre Spiegel
                Last commenter:
                Kay Kim
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created:
                  Days since reply:
                  4 years, 35 weeks, 1 day ago