[SERVER-4397] Log table scans. Created: 30/Nov/11 Updated: 30/Jan/15 Resolved: 30/Jan/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Logging, Querying |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Kyle Banker | Assignee: | David Storch |
| Resolution: | Duplicate | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Description |
|
If a query or a command (such as count) is doing a table scan, we should note that in the logs explicitly. In addition, we should add a table scans counter for both queries and commands to the server status results. That way, we can graphs table scans in MMS. This would help us diagnose these kinds of problems without having to look at the logs. If it's difficult to determine exactly what qualifies as a table scan, I'd recommend a simple heuristic. For instance, we could log whenever nscanned > 10n and when nscanned > 1000. |
| Comments |
| Comment by David Storch [ 30/Jan/15 ] | ||||
|
In 2.6 and onwards, the query plan is included in the planSummary field of the query log lines. This work was done under
A 2.6.7 server generates the following log line:
Closing as a duplicate of |