Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-16592

bad order search logic in Geonear

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Geo, Index Maintenance, Querying
    • Labels:
      None
    • ALL
    • Hide
      db.runCommand( { 
          
          geoNear: "tablegui",
          near: [2.298800, 48.854355], 
          spherical: true, 
          distanceMultiplier: 6371 ,     
           query: { code_postal : 2 },
           maxDistance:2000/6371  ,
          limit:1500 }
          );
      
      Show
      db.runCommand( { geoNear: "tablegui" , near: [2.298800, 48.854355], spherical: true , distanceMultiplier: 6371 , query: { code_postal : 2 }, maxDistance:2000/6371 , limit:1500 } );

      Hi ,
      When using geoNear, i add a conditional query(who match nothing) ,
      but result is very long because the order is to first scan all geo matching..
      This is illogical, it takes 0,00001 to see thats the conditional query return nothing, and it takes many time to search all geo distance .
      Why don't search simple query filter before complex query filter ?

      consider this query , tested with all possible indexation cases

      db.runCommand( { 
          
          geoNear: "tablegui",
          near: [2.298800, 48.854355], 
          spherical: true, 
          distanceMultiplier: 6371 ,     
           query: { code_postal : 2 },
           maxDistance:2000/6371  ,
          limit:1500 }
          );
      

      There is no code_postal value with 2 , the query take very long time to search distance first...
      Somethings is wrong or i miss something ?

      regards
      pulsar

            Assignee:
            siyuan.zhou@mongodb.com Siyuan Zhou
            Reporter:
            pulsar guipulsar
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: