diff options
| -rw-r--r-- | sql/opt_range.cc | 3 | ||||
| -rw-r--r-- | sql/opt_range.h | 5 |
2 files changed, 2 insertions, 6 deletions
diff --git a/sql/opt_range.cc b/sql/opt_range.cc index 2435492061e..cc7372bbc87 100644 --- a/sql/opt_range.cc +++ b/sql/opt_range.cc @@ -4696,8 +4696,7 @@ ROR_SCAN_INFO *make_ror_scan(const PARAM *param, int idx, SEL_ARG *sel_arg) bitmap_set_bit(&ror_scan->covered_fields, key_part->fieldnr-1); } ror_scan->index_read_cost= - param->table->file->keyread_time(ror_scan->keynr, 1, - param->table->quick_rows[ror_scan->keynr]); + param->table->file->keyread_time(ror_scan->keynr, 1, ror_scan->records); DBUG_RETURN(ror_scan); } diff --git a/sql/opt_range.h b/sql/opt_range.h index 1e3008d78aa..cef9739168f 100644 --- a/sql/opt_range.h +++ b/sql/opt_range.h @@ -457,11 +457,8 @@ public: INDEX MERGE OPTIMIZER Current implementation doesn't detect all cases where index_merge could be used, in particular: - * index_merge will never be used if range scan is possible (even if - range scan is more expensive) - * index_merge+'using index' is not supported (this the consequence of - the above restriction) + * index_merge+'using index' is not supported * If WHERE part contains complex nested AND and OR conditions, some ways to retrieve rows using index_merge will not be considered. The choice |