log_slow_filter=qc_miss inconsistent with QC_hit: in the slow query log
Bug #1046349 reported by
Laurynas Biveinis
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Percona Server moved to https://jira.percona.com/projects/PS | Status tracked in 5.7 | |||||
5.1 |
Invalid
|
Undecided
|
Unassigned | |||
5.5 |
Invalid
|
Undecided
|
Unassigned | |||
5.6 |
Triaged
|
Wishlist
|
Unassigned | |||
5.7 |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
We cannot fix this for 5.1 and 5.5, but we should consider replacing the qc_miss option value with qc_hit for 5.6.
tags: | added: slow-extended |
To post a comment you must log in.
Actually, both qc_hit and qc_miss will be better.
However, currently qc_miss can be filtered, so documentation for 5.5 http:// www.percona. com/doc/ percona- server/ 5.5/diagnostics /slow_extended_ 55.html -- needs to be fixed (s/qc_hit/qc_miss), documentation for 5.1 PS is correct.
The current logic for qc_miss is as follows:
1. ((thd-> variables. log_slow_ filter & SLOG_F_QC_NO) &&
(thd-> query_plan_ flags & QPLAN_QC))))
2.
((thd- >query_ plan_flags & QPLAN_QC) ? "Yes" : "No"),
"# QC_Hit: %s Full_scan: %s Full_join: %s Tmp_table: %s Tmp_table_on_disk: %s\n" \
"# Filesort: %s Filesort_on_disk: %s Merge_passes: %lu\n",
So, from #1 and #2,
if filter has query cache miss set and query was cached, it skips logging it, and QC_Hit will 1 but will not be logged
if filter has query cache miss set and query indeed missed the cache,it logs it and QC_Hit will be logged as 0 in the log
Now, the rationale behind logging query misses with a filter may have been that query cache hits (qc_hits with QC_Hit 1) generally aren't slow whereas qc misses generally hurt the performance.
Also, people may be interested in slow queries which don't fit the profile of filesort*, full_*, tmp_* but are still interested in ones which escape that, setting log_slow_ filter= qc_miss seems to be the only way to log such queries.
However, people may also be interested in having query cache hits specifically filtered (to diagnose query cache issues), so having that makes sense as well. I guess, having something like invertible elements is better (not sure if such a type is supported in 5.6) like -- log_slow_ filter= !qc_miss, !filesort