diff options
author | Sergei Golubchik <sergii@pisem.net> | 2014-06-06 00:07:27 +0200 |
---|---|---|
committer | Sergei Golubchik <sergii@pisem.net> | 2014-06-06 00:07:27 +0200 |
commit | e27c338634739ef56a6888e7948e04c0fa0ba677 (patch) | |
tree | ad63ccae614f3dd77509825d1905fd815ef322cb /sql/sql_select.cc | |
parent | 2a5905141a3c509a7c34c3d370fb146dbc1c965f (diff) | |
parent | 6d75570e99fbf070cdbeefdfbcfc94d1c7b3ad1f (diff) | |
download | mariadb-git-e27c338634739ef56a6888e7948e04c0fa0ba677.tar.gz |
5.5.38 merge
Diffstat (limited to 'sql/sql_select.cc')
-rw-r--r-- | sql/sql_select.cc | 32 |
1 files changed, 19 insertions, 13 deletions
diff --git a/sql/sql_select.cc b/sql/sql_select.cc index 5db11f3d339..d430e8bc10d 100644 --- a/sql/sql_select.cc +++ b/sql/sql_select.cc @@ -1248,7 +1248,8 @@ TODO: make view to decide if it is possible to write to WHERE directly or make S part of the nested outer join, and we can't do partition pruning (TODO: check if this limitation can be lifted) */ - if (!tbl->embedding) + if (!tbl->embedding || + (tbl->embedding && tbl->embedding->sj_on_expr)) { Item *prune_cond= tbl->on_expr? tbl->on_expr : conds; tbl->table->all_partitions_pruned_away= prune_partitions(thd, @@ -11017,20 +11018,25 @@ make_join_readinfo(JOIN *join, ulonglong options, uint no_jbuf_after) else if (!table->covering_keys.is_clear_all() && !(tab->select && tab->select->quick)) { // Only read index tree + if (tab->loosescan_match_tab) + tab->index= tab->loosescan_key; + else + { #ifdef BAD_OPTIMIZATION - /* - It has turned out that the below change, while speeding things - up for disk-bound loads, slows them down for cases when the data - is in disk cache (see BUG#35850): - See bug #26447: "Using the clustered index for a table scan - is always faster than using a secondary index". - */ - if (table->s->primary_key != MAX_KEY && - table->file->primary_key_is_clustered()) - tab->index= table->s->primary_key; - else + /* + It has turned out that the below change, while speeding things + up for disk-bound loads, slows them down for cases when the data + is in disk cache (see BUG#35850): + See bug #26447: "Using the clustered index for a table scan + is always faster than using a secondary index". + */ + if (table->s->primary_key != MAX_KEY && + table->file->primary_key_is_clustered()) + tab->index= table->s->primary_key; + else #endif - tab->index=find_shortest_key(table, & table->covering_keys); + tab->index=find_shortest_key(table, & table->covering_keys); + } tab->read_first_record= join_read_first; /* Read with index_first / index_next */ tab->type= tab->type == JT_ALL ? JT_NEXT : JT_HASH_NEXT; |