Details
-
Task
-
Status: Stalled (View Workflow)
-
Minor
-
Resolution: Unresolved
-
None
-
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
Attachments
Issue Links
- relates to
-
-
- Closed
-
Activity
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)
Roberto,
what was the use case for this feature? Filtering out QC hits?