mirror of
https://github.com/MariaDB/server.git
synced 2025-07-29 05:21:33 +03:00
Change cost for REF to take into account cost for 1 extra key read_next
The main difference in code path between EQ_REF and REF is that for REF we have to do an extra read_next on the index to check that there is no more matching rows. Before this patch we added a preference of EQ_REF by ensuring that REF would always estimate to find at least 2 rows. This patch adds the cost of the extra key read_next to REF access and removes the code that limited REF to at least 2 rows. For some queries this can have a big effect as the total estimated rows will be halved for each REF table with 1 rows. multi_range cost calculations are also changed to take into account the difference between EQ_REF and REF. The effect of the patch to the test suite: - About 80 test case changed - Almost all changes where for EXPLAIN where estimated rows for REF where changed from 2 to 1. - A few test cases using explain extended had a change of 'filtered'. This is because of the estimated rows are now closer to the calculated selectivity. - A very few test had a change of table order. This is because the change of estimated rows from 2 to 1 or the small cost change for REF (main.subselect_sj_jcl6, main.group_by, main.dervied_cond_pushdown, main.distinct, main.join_nested, main.order_by, main.join_cache) - No key statistics and the estimated rows are now smaller which cased estimated filtering to be lower. (main.subselect_sj_mat) - The number of total rows are halved. (main.derived_cond_pushdown) - Plans with 1 row changed to use RANGE instead of REF. (main.group_min_max) - ALL changed to REF (main.key_diff) - Key changed from ref + index_only to PRIMARY key for InnoDB, as OPTIMIZER_ROW_LOOKUP_COST + OPTIMIZER_ROW_NEXT_FIND_COST is smaller than OPTIMIZER_KEY_LOOKUP_COST + OPTIMIZER_KEY_NEXT_FIND_COST. (main.join_outer_innodb) - Cost changes printouts (main.opt_trace*) - Result order change (innodb_gis.rtree)
This commit is contained in:
@ -552,12 +552,12 @@ a b
|
||||
3 1
|
||||
explain select t1.a,t2.b from t1,t2 where t1.a=t2.a group by t1.a,t2.b;
|
||||
id select_type table type possible_keys key key_len ref rows Extra
|
||||
1 SIMPLE t2 ALL a NULL NULL NULL 4 Using temporary; Using filesort
|
||||
1 SIMPLE t1 ALL NULL NULL NULL NULL 6 Using where; Using join buffer (flat, BNL join)
|
||||
1 SIMPLE t1 ALL NULL NULL NULL NULL 6 Using temporary; Using filesort
|
||||
1 SIMPLE t2 ref a a 4 test.t1.a 1
|
||||
explain select t1.a,t2.b from t1,t2 where t1.a=t2.a group by t1.a,t2.b ORDER BY NULL;
|
||||
id select_type table type possible_keys key key_len ref rows Extra
|
||||
1 SIMPLE t2 ALL a NULL NULL NULL 4 Using temporary
|
||||
1 SIMPLE t1 ALL NULL NULL NULL NULL 6 Using where; Using join buffer (flat, BNL join)
|
||||
1 SIMPLE t1 ALL NULL NULL NULL NULL 6 Using temporary
|
||||
1 SIMPLE t2 ref a a 4 test.t1.a 1
|
||||
drop table t1,t2;
|
||||
SET @@optimizer_use_condition_selectivity=@save_optimizer_use_condition_selectivity,@@optimizer_switch=@save_optimizer_switch;
|
||||
create table t1 (a int, b int);
|
||||
@ -1972,8 +1972,8 @@ SELECT a, AVG(t1.b),
|
||||
FROM t1 GROUP BY a;
|
||||
id select_type table type possible_keys key key_len ref rows Extra
|
||||
1 PRIMARY t1 index NULL a 10 NULL 9 Using index
|
||||
3 DEPENDENT SUBQUERY t12 ref a a 10 func,func 2 Using index condition
|
||||
2 DEPENDENT SUBQUERY t11 ref a a 10 func,func 2 Using index condition
|
||||
3 DEPENDENT SUBQUERY t12 ref a a 10 func,func 1 Using index condition
|
||||
2 DEPENDENT SUBQUERY t11 ref a a 10 func,func 1 Using index condition
|
||||
SELECT a, AVG(t1.b),
|
||||
(SELECT t11.c FROM t1 t11 WHERE t11.a = t1.a AND t11.b = AVG(t1.b)) AS t11c,
|
||||
(SELECT t12.c FROM t1 t12 WHERE t12.a = t1.a AND t12.b = AVG(t1.b)) AS t12c
|
||||
|
Reference in New Issue
Block a user