diff options
author | Varun Gupta <varunraiko1803@gmail.com> | 2017-09-24 23:37:57 +0530 |
---|---|---|
committer | Varun Gupta <varunraiko1803@gmail.com> | 2017-09-24 23:37:57 +0530 |
commit | f91eb71e1cfaac56aa1c14b3681dbff3edc7eb0c (patch) | |
tree | 999dbd407ba75d263a1047a57382c3fd32eb3543 | |
parent | ea2162b6aae020117bc5e0422b8e4629498163bf (diff) | |
download | mariadb-git-f91eb71e1cfaac56aa1c14b3681dbff3edc7eb0c.tar.gz |
MDEV-8840: ANALYZE FORMAT=JSON produces wrong data with BKA
The issue was that r_loops, r_rows and r_filtered in ANALYZE FORMAT= JSON were not
calculated for the table on which we were performing the MRR scan in the BKA join
Fixed this by adding respective counter in the JOIN_TAB_SCAN_MRR::open and JOIN_TAB_SCAN_MRR::next
-rw-r--r-- | mysql-test/r/explain_json.result | 6 | ||||
-rw-r--r-- | sql/sql_join_cache.cc | 3 |
2 files changed, 6 insertions, 3 deletions
diff --git a/mysql-test/r/explain_json.result b/mysql-test/r/explain_json.result index a46a3bcefa5..9e5515f3cfa 100644 --- a/mysql-test/r/explain_json.result +++ b/mysql-test/r/explain_json.result @@ -1524,12 +1524,12 @@ ANALYZE "key_length": "5", "used_key_parts": ["a"], "ref": ["test.t3.a"], - "r_loops": 0, + "r_loops": 1, "rows": 1, - "r_rows": null, + "r_rows": 10, "r_total_time_ms": "REPLACED", "filtered": 100, - "r_filtered": null, + "r_filtered": 100, "index_condition_bka": "((t4.b + 1) <= (t3.b + 1))" }, "buffer_type": "flat", diff --git a/sql/sql_join_cache.cc b/sql/sql_join_cache.cc index 1023aea4cd4..75e69298809 100644 --- a/sql/sql_join_cache.cc +++ b/sql/sql_join_cache.cc @@ -3877,6 +3877,7 @@ int JOIN_TAB_SCAN_MRR::open() /* Dynamic range access is never used with BKA */ DBUG_ASSERT(join_tab->use_quick != 2); + join_tab->tracker->r_scans++; save_or_restore_used_tabs(join_tab, FALSE); init_mrr_buff(); @@ -3920,6 +3921,8 @@ int JOIN_TAB_SCAN_MRR::next() int rc= join_tab->table->file->multi_range_read_next((range_id_t*)ptr) ? -1 : 0; if (!rc) { + join_tab->tracker->r_rows++; + join_tab->tracker->r_rows_after_where++; /* If a record in in an incremental cache contains no fields then the association for the last record in cache will be equal to cache->end_pos |