diff options
| author | Igor Babaev <igor@askmonty.org> | 2012-03-13 13:34:20 -0700 |
|---|---|---|
| committer | Igor Babaev <igor@askmonty.org> | 2012-03-13 13:34:20 -0700 |
| commit | c1f5e25c045538309e9da7aa2d9f0e4bd189977d (patch) | |
| tree | 35a435eb0554db02c3a8fe5d0895d28a1d06e07b /sql | |
| parent | 223483aedf0c53bc66cb6833210228b46448003a (diff) | |
| download | mariadb-git-c1f5e25c045538309e9da7aa2d9f0e4bd189977d.tar.gz | |
Fixed LP bug #953649.
Do not call, directly or indirectly, SQL_SELECT::test_quick_select()
for derived materialized tables / views when optimizing joins referring
to these tables / views to get cost estimates of materialization.
The current code does not create B-tree indexes for materialized
derived tables / views. So now it's not possible to get any estimates
for ranges conditions over the results of the materialization.
The function mysql_derived_create() must take into account the fact
that array of the KEY structures specifying the keys over a derived
table / view may be moved after the optimization phase if the
derived table / view is materialized.
Diffstat (limited to 'sql')
| -rw-r--r-- | sql/sql_derived.cc | 1 | ||||
| -rw-r--r-- | sql/sql_select.cc | 14 |
2 files changed, 10 insertions, 5 deletions
diff --git a/sql/sql_derived.cc b/sql/sql_derived.cc index 02a26254336..99d20090623 100644 --- a/sql/sql_derived.cc +++ b/sql/sql_derived.cc @@ -811,6 +811,7 @@ bool mysql_derived_create(THD *thd, LEX *lex, TABLE_LIST *derived) select_union *result= (select_union*)unit->result; if (table->s->db_type() == TMP_ENGINE_HTON) { + result->tmp_table_param.keyinfo= table->s->key_info; if (create_internal_tmp_table(table, result->tmp_table_param.keyinfo, result->tmp_table_param.start_recinfo, &result->tmp_table_param.recinfo, diff --git a/sql/sql_select.cc b/sql/sql_select.cc index 437833eb90c..31d87905da6 100644 --- a/sql/sql_select.cc +++ b/sql/sql_select.cc @@ -3513,12 +3513,16 @@ make_join_statistics(JOIN *join, List<TABLE_LIST> &tables_list, Perform range analysis if there are keys it could use (1). Don't do range analysis if we're on the inner side of an outer join (2). Do range analysis if we're on the inner side of a semi-join (3). + Don't do range analysis for materialized subqueries (4). + Don't do range analysis for materialized derived tables (5) */ - if (!s->const_keys.is_clear_all() && // (1) - (!s->table->pos_in_table_list->embedding || // (2) - (s->table->pos_in_table_list->embedding && // (3) - s->table->pos_in_table_list->embedding->sj_on_expr)) && // (3) - !s->table->is_filled_at_execution()) + if (!s->const_keys.is_clear_all() && // (1) + (!s->table->pos_in_table_list->embedding || // (2) + (s->table->pos_in_table_list->embedding && // (3) + s->table->pos_in_table_list->embedding->sj_on_expr)) && // (3) + !s->table->is_filled_at_execution() && // (4) + !(s->table->pos_in_table_list->derived && // (5) + s->table->pos_in_table_list->is_materialized_derived())) // (5) { ha_rows records; SQL_SELECT *select; |