[SERVER-4491] count() on a find() returns scanned count instead of result count Created: 14/Dec/11 Updated: 07/Apr/23 Resolved: 19/Dec/11 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 2.0.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Frédéric G. MARAND | Assignee: | Aaron Staple |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | count, find | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Ubuntu 11.04, Linux bs-linux64.10gen.cc 2.6.21.7-2.ec2.v1.2.fc8xen #1 SMP Fri Nov 20 17:48:28 EST 2009 x86_64 BOOST_LIB_VERSION=1_41 |
||
| Attachments: |
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Operating System: | Linux | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
On a largeish collection, results from count() applied to a query appear to return the number of scanned objects instead of the number of objects returned by the find(): db.activity.findOne( {'datacache.user.id': null}) > db.activity.find( {'datacache.user.id': null}) > db.activity.find( {'datacache.user.id': null}).count() > db.activity.count( {'datacache.user.id': null}) > db.activity.find( {'datacache.user.id': null}).explain() } Searching for values besides null in that collection is inconclusive: result count always matches scanned count in such cases, they only differ for null. |
| Comments |
| Comment by Aaron Staple [ 19/Dec/11 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Julien, The root cause here is If you need to run this query on your production system, I'd suggest doing a normal find and counting the results rather than running the count command for this specific query. If you run into performance issues doing that, I can make some alternative suggestions that would be faster. I am going to close out this ticket as a duplicate of | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Aaron Staple [ 19/Dec/11 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Julien, I think I'm figuring out what the main issue is, but also it looks like your document output is messed up. It is malformed json because there are some commas missing. Did you paste the output verbatim from the shell, or did you modify it to remove confidential information? If you did modify the document, could you instead modify it by replacing fields with dummy information (like 'XXXXXXXX' or something ) instead of removing them? Thanks, | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Julien Dubreuil [ 19/Dec/11 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Aaron, Effectively, I should have done a db.activity.getIndexes() to see the structure of my indexes. You were right, only names are differents, keys patterns are the same. Here is the output of the db.activity.getIndexes():
And here is the output of your requested command :
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Aaron Staple [ 16/Dec/11 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Julien, I'm not that familiar with the php driver, but what you are basically looking at here are the index names - which are generated based on the index key pattern but are actually pretty arbitrary. My guess is that php and the shell are generating slightly different names but the same key pattern. To see some more detailed information about indexes you can run db.activity.getIndexes(). Would be great if you can send the output of getIndexes(). Also, to try and diagnose the situation further, could you please run the following and send me the output: db.activity.find().min( {'datacache.user.id':null}).sort( {'datacache.user.id':1})[0] Thanks, | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Julien Dubreuil [ 16/Dec/11 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Aaron Yeah, that's true, but I thought I had made a mistake when a did db.activity.ensureIndex( {'datacache.user.id' : 1}), because it doesn't looks like ot others index.
Maybe I missed some things, but why when I created an index using the php drivers and Mongo shell I don't have the same result. With PHP
With Mongo shell
What are the differences between datacache_user_id_1 and datacache.user.id_1 ? Anyway, I did it again with the Mongo shell and the problem is still there :
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Aaron Staple [ 16/Dec/11 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Julien, It looks like there is an error where you are recreating your index. You ran: db.activity.ensureIndex( {'datacache_user_id' : 1}) but it needs to be: db.activity.ensureIndex( {'datacache.user.id' : 1}) If you rebuild a v1 index as I described and still see this problem, we can further diagnose the situation. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Julien Dubreuil [ 15/Dec/11 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Aaron I'm working with Frederic on our project based on MongoDB Here is a copy of my indexes (ready to discuss with you about optimization
We always used a Mongo 2.0 for our project, so indexes were not created on an earlier version. As you requested, I've dropped indexes, tested it, recreated it and then the problem has gone.
It should be noted, after the restoration of the datas, I did a big update on to the structure of every documents of the collection in order to change the non indexable sub-document structure. So, what I've done : Maybe it's not reproducible and not really a bug, but one thing's sure, my update is in cause Thanks, Julien | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Aaron Staple [ 14/Dec/11 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Frederic - I created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Aaron Staple [ 14/Dec/11 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Frederic, I think this is an issue with v0 indexes combined with some new multikey index matching behavior in mongo 2.0. Did you originally create your index with an earlier version of mongo? I am going to file a separate ticket for what I think is the root cause, I just want to confirm that it's actually the cause of your problem. Aaron | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Aaron Staple [ 14/Dec/11 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Frederic, If you recreate the index, does the issue start happening again? Thanks, | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Frédéric G. MARAND [ 14/Dec/11 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This looks like an issue with indexes: I removed the "datacache_user_id_1" index and reran the queries: db.activity.find( {'datacache.user.id': null}) > db.activity.findOne( {'datacache.user.id': null}) > db.activity.find( {'datacache.user.id': null}).count() db.activity.find( {'datacache.user.id': null}).explain() } |