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

bad order search logic in Geonear

    XMLWordPrintableJSON

Details

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major - P3 Major - P3
    • None
    • None
    • Geo, Index Maintenance, Querying
    • 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 } );

    Description

      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

      Attachments

        Activity

          People

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

            Dates

              Created:
              Updated:
              Resolved: