database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-07-29 05:21:33 +03:00
Code Activity

MDEV-17752: Plan changes from hash_index_merge to index_merge with new optimizer defaults

Browse Source 
The code in best_access_path function, when it does not find a key suitable for ref access
and join_cache_level is set to a value so that hash_join is possible we build a hash key.
Later in the function we compare the cost of ref access with table scan (or index scan
or quick selects). No need to do this when we have got the hash key.
This commit is contained in:
Varun Gupta
2019-05-20 17:44:55 +05:30
parent aaa920dad3
commit 6dbc2ab8b3
4 changed files with 69 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
sql/sql_select.cc
View File

@ -6396,7 +6396,8 @@ best_access_path(JOIN *join,
'range' access using index IDX, and the best way to perform 'ref'
access is to use the same index IDX, with the same or more key parts.
(note: it is not clear how this rule is/should be extended to
index_merge quick selects)
index_merge quick selects). Also if we have a hash join we prefer that
over a table scan
(3) See above note about InnoDB.
(4) NOT ("FORCE INDEX(...)" is used for table and there is 'ref' access
path, but there is no quick select)
@ -6412,6 +6413,7 @@ best_access_path(JOIN *join,
be used for cases with small datasets, which is annoying.
*/
if ((records >= s->found_records || best > s->read_time) && // (1)
!(best_key && best_key->key == MAX_KEY) && // (2)
!(s->quick && best_key && s->quick->index == best_key->key && // (2)
best_max_key_part >= s->table->quick_key_parts[best_key->key]) &&// (2)
!((s->table->file->ha_table_flags() & HA_TABLE_SCAN_ON_INDEX) && // (3)