[SERVER-23332] Expose query plan cache key in system.profile entry and query log lines Created: 24/Mar/16 Updated: 13/Aug/18 Resolved: 31/Jul/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Logging, Querying |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.2 |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Shakir Sadikali | Assignee: | Haley Connelly |
| Resolution: | Done | Votes: | 3 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||
| Sprint: | Query 2018-07-16, Query 2018-07-30, Query 2018-08-13 | ||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||
| Description |
|
It would be nice if we included a hash of all queries (without their binds) so we can get a sense for unique types of queries being run on a system and to be able to get a better performance profile for "bad" queries. If we could add that hash into the mongod.log we can easily "group" queries for prioritization when telling the customer what to "tweak". |
| Comments |
| Comment by Githook User [ 31/Jul/18 ] |
|
Author: {'name': 'Haley Connelly', 'email': 'haley.connelly@10gen.com', 'username': 'haleyConnelly'}Message: |
| Comment by Ian Whalen (Inactive) [ 08/Jun/18 ] |
|
Just a note that this should be expanded to include the plan cache introspection commands. |
| Comment by David Storch [ 28/Aug/17 ] |
|
Copying in some more context from kevin.arhelger in
|
| Comment by David Storch [ 25/Mar/16 ] |
|
shakir.sadikali thanks for elaborating. I do believe that if we map this request from Oracle terminology to MongoDB terminology, the idea is to expose the plan cache key in system.profiler (and probably also in the logs). I am going to update the summary of the ticket accordingly, as this will allow the query team developers to more quickly understand the feature request. Please let me know if you think my interpretation is not accurate. |
| Comment by Shakir Sadikali [ 24/Mar/16 ] |
|
david.storch Perhaps we're using different terminology. Ideally, I would parse out all the bind variables and then create a "hash key" of the query text and use that as a unique identifier to any unique parsed query. I would then be able to use that to perform reporting (i.e. how often is a query executing, what's it's plan, number of I/O aggregate and per exec, time on CPU...etc. This would be analogous to v$sql_area, v$sql_plan, etc. in Oracle. I consider system.profile analogous to v$active_session_history. |
| Comment by David Storch [ 24/Mar/16 ] |
|
shakir.sadikali, I'm not sure I understand this request. Are you suggesting that we add the internal plan cache key to the query log line? The plan cache key is a sequence of bytes, generated from the parsed query, which we use internally as our concept of "query shape". |