[SERVER-13132] Query ignoring indexes in 2.6rc1 Created: 11/Mar/14  Updated: 11/Jul/16  Resolved: 12/Mar/14

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: 2.6.0-rc1
Fix Version/s: 2.6.0-rc2

Type: Bug Priority: Major - P3
Reporter: Wiliam Assignee: David Storch
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 8.1, php 5.4.4, php-mongo-driver 1.3.1, Mongo 2.6rc1


Issue Links:
Related
Operating System: Windows
Participants:

 Description   

After updating from 2.4.5 to 2.6rc1 in a local environment, we tested the next query:

{
  "namespace" : "rsvcom",
  "active" : true,
  "$or" : [{
      "keywords.names" : /^hotel/
    }, {
      "keywords.extended" : {
        "$all" : [/^hotel/]
      }
    }],
  "searchable" : true,
  "type" : "EA"
}

The collection "suggest" has 2.414.690 documents with a size of 2.5gb and a index size of 3.4gb.

The output of db.suggest.getIndexes() is here:
https://gist.github.com/wiliame/4439872fa5e3741163d5

And the issue comes with the index selector, the query is taking more than 20 seconds, sometimes some minutes to finish because is scanning all the documents.

Explain of the query in the 2.6rc1:
https://gist.github.com/wiliame/391289227b62871ab0e4

Explain of the query in the 2.4.5:
https://gist.github.com/wiliame/414c22f0c6f6981fbea9

And the output is not the expected.

To finish, this are some example documents:
https://gist.github.com/wiliame/56c771b422f27fe0ed95



 Comments   
Comment by Daniel Pasette (Inactive) [ 17/Mar/14 ]

Can you give more information about what you mean by "data has been corrupted with the 2.6.1-rc1 version"?

Comment by Wiliam [ 16/Mar/14 ]

Data has been corrupted with the 2.6rc1 version, I'm restoring a backup to try again, but for now your fix works fine.

Comment by hari.khalsa@10gen.com [ 13/Mar/14 ]

And, if you don't mind, can you also provide log files? This message can sometimes mean database corruption. If you have a reliable reproduction that's the most useful for diagnosing it, but in absence of that, log files are helpful as well.

Comment by hari.khalsa@10gen.com [ 13/Mar/14 ]

There is likely be more information available from the mongod for that assertion (like a stack trace). Can you provide that? Alternatively, can you provide a way to reliably reproduce it?

Comment by Wiliam [ 13/Mar/14 ]

I have tried the last version with this fix and I'm getting a new error message only at that collection in every count.

BSONObj size: 0 (0x0) is invalid. Size must be between 0 and 16793600(16MB) First element: EOO
Exception code: 10334

Comment by Wiliam [ 12/Mar/14 ]

Thanks, I will try the rc2.

Comment by David Storch [ 12/Mar/14 ]

Hi William, I just pushed some changes to the plan ranking logic which hopefully should resolve your issue. This will be available in the next release candidate (2.6.0-rc2). Thanks for the bug report, and please let us know if you continue to experience related problems.

Comment by Githook User [ 12/Mar/14 ]

Author:

{u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}

Message: SERVER-13132 run candidates plans for longer
Branch: v2.6
https://github.com/mongodb/mongo/commit/e972301dfc613bd7095a35024823f9d82a9fed37

Comment by Githook User [ 12/Mar/14 ]

Author:

{u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}

Message: SERVER-13132 run candidates plans for longer
Branch: master
https://github.com/mongodb/mongo/commit/5b33dcf8eca51d1356d80099ef45276f55353dfc

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