Details
-
Type:
Task
-
Status: Stalled
-
Priority:
Major
-
Resolution: Unresolved
-
Fix Version/s: 10.1
-
Component/s: None
-
Labels:None
Description
Include two new columns to QUERY_RESPONSE_TIME:
query_cache_count => number of queries returned from query cache
query_cache_total => query cache response time
the non query cache queries could be found as:
SELECT
time,
count,
total,
query_cache_count,
query_cache_total,
(count-query_cache_count) AS non_query_cache_count,
(total-query_cache_total) AS non_query_cache_total
FROM QUERY_RESPONSE_TIME
Gliffy Diagrams
Attachments
Issue Links
- relates to
-
-
- Closed
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Roberto,
what was the use case for this feature? Filtering out QC hits?
For current mdev, know what was the exactly time take from standard queriess and query cached queriess, usefull to fine tune apps
Fornthe other mdev, know if a query cached is a good/bad cached query and agaim fine tune app and query cache use
Quoting Sergei's review:
Queries served from qc don't take much time, which means that @@query_response_time_range_base should be different for them. Otherwise all qc hits will be in the first few slots. But a different base means a different table (QUERY_CACHE_RESPONSE_TIME ?) and a different set of configuration variables.
Isn't it the case?
Well from my tests with a pentium 3 i got 30ms from query cache, the biggest qc return was 147 ms ,
just to add a comment and a feature usefull..
when we restart the stats should be nice when it happened, maybe a status variable (show status) reporting the last flush could be very usefull to get informatino about "queries/second" (now-flush datetime)
MUST create unit test patch