[SERVER-20281] Looks like optimizer choose improper index or full-scan sometimes. Created: 03/Sep/15 Updated: 08/Feb/23 Resolved: 26/Sep/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | MMAPv1, Performance |
| Affects Version/s: | 2.4.14 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | 아나 하리 | Assignee: | Sam Kleinman (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Steps To Reproduce: | Don't know. |
| Participants: |
| Description |
|
Looks like optimizer choose improper index or doing full scan sometimes. But execution plan is good when I execute this query manually. But looks like sometimes query running different way. Weird thing is that I can not find documents which is matching "creator_id" even during this pattern of query is running. Is there any way to tell the execution plan this query choose?
|
| Comments |
| Comment by Ramon Fernandez Marina [ 26/Sep/15 ] |
|
matt.lee, I'm going to close this issue since we haven't heard back from your for a while. As Dan mentioned you can use explain() to find out why a specific query plan was chosen. And as Sam mentioned, if this behavior turns out to be a bug in 2.4 the recommended approach is to upgrade to the latest stable release (3.0.6 at the time of this writing). Regards, |
| Comment by Sam Kleinman (Inactive) [ 09/Sep/15 ] |
|
Hi Matt, I wanted to check in and see if you were able to reproduce this issue on a different version, or if you were able to find what you needed using the 2.4 explain() method. Regards, |
| Comment by Daniel Pasette (Inactive) [ 04/Sep/15 ] |
|
You can still run an explain on the query to understand which index was chosen in 2.4 Here's the documentation for the 2.4 branch: |
| Comment by 아나 하리 [ 03/Sep/15 ] |
|
Hi Sam. So there's no way to introspecting what optimizer doing in MongoDB 2.4. Regards, |
| Comment by Sam Kleinman (Inactive) [ 03/Sep/15 ] |
|
I just want to confirm that you're seeing this issue in 2.4 of MongoDB. The query system underwent many improvements in the 2.6 release. Have you tried to reproduce this issue in 2.6 or 3.0? Additionally, query introspection (i.e. the profiler, the explain operation, and slowms logging) was improved substantially for the 3.0 release which should provide some of the additional data that will help you address these issues. Regards, |
| Comment by 아나 하리 [ 03/Sep/15 ] |
|
And slow query logging of mongodb log file doesn't tell me how many documents are scanned(nscanned field) for this case. Is it normal ? |