summaryrefslogtreecommitdiff
path: root/mysql-test/r/group_by.result
diff options
context:
space:
mode:
authorIgor Babaev <igor@askmonty.org>2014-04-22 14:39:57 -0700
committerIgor Babaev <igor@askmonty.org>2014-04-22 14:39:57 -0700
commit3e0f63c18fdfae9280fb406c4677c613d1838a64 (patch)
tree3210f3b7436ff1d36a059bf3ec967515d9faa959 /mysql-test/r/group_by.result
parentbd44c086b33a7b324ac41f8eb0826c31da1c4103 (diff)
downloadmariadb-git-3e0f63c18fdfae9280fb406c4677c613d1838a64.tar.gz
Fixed the problem of mdev-5947.
Back-ported from the mysql 5.6 code line the patch with the following comment: Fix for Bug#11757108 CHANGE IN EXECUTION PLAN FOR COUNT_DISTINCT_GROUP_ON_KEY CAUSES PEFORMANCE REGRESSION The cause for the performance regression is that the access strategy for the GROUP BY query is changed form using "index scan" in mysql-5.1 to use "loose index scan" in mysql-5.5. The index used for group by is unique and thus each "loose scan" group will only contain one record. Since loose scan needs to re-position on each "loose scan" group this query will do a re-position for each index entry. Compared to just reading the next index entry as a normal index scan does, the use of loose scan for this query becomes more expensive. The cause for selecting to use loose scan for this query is that in the current code when the size of the "loose scan" group is one, the formula for calculating the cost estimates becomes almost identical to the cost of using normal index scan. Differences in use of integer versus floating point arithmetic can cause one or the other access strategy to be selected. The main issue with the formula for estimating the cost of using loose scan is that it does not take into account that it is more costly to do a re-position for each "loose scan" group compared to just reading the next index entry. Both index scan and loose scan estimates the cpu cost as: "number of entries needed too read/scan" * ROW_EVALUATE_COST The results from testing with the query in this bug indicates that the real cost for doing re-position four to eight times higher than just reading the next index entry. Thus, the cpu cost estimate for loose scan should be increased. To account for the extra work to re-position in the index we increase the cost for loose index scan to include the cost of navigating the index. This is modelled as a function of the height of the b-tree: navigation cost= ceil(log(records in table)/log(indexes per block)) * ROWID_COMPARE_COST; This will avoid loose index scan being used for indexes where the "loose scan" group contains very few index entries.
Diffstat (limited to 'mysql-test/r/group_by.result')
-rw-r--r--mysql-test/r/group_by.result12
1 files changed, 6 insertions, 6 deletions
diff --git a/mysql-test/r/group_by.result b/mysql-test/r/group_by.result
index dfe28f0e05a..9b86ccd264e 100644
--- a/mysql-test/r/group_by.result
+++ b/mysql-test/r/group_by.result
@@ -1524,7 +1524,7 @@ id select_type table type possible_keys key key_len ref rows Extra
EXPLAIN SELECT a FROM t1 FORCE INDEX FOR JOIN (i2)
FORCE INDEX FOR GROUP BY (i2) GROUP BY a;
id select_type table type possible_keys key key_len ref rows Extra
-1 SIMPLE t1 range NULL i2 4 NULL 145 Using index for group-by
+1 SIMPLE t1 index NULL i2 9 NULL 144 Using index
EXPLAIN SELECT a FROM t1 USE INDEX () IGNORE INDEX (i2);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 ALL NULL NULL NULL NULL 144
@@ -1957,12 +1957,12 @@ UNIQUE INDEX idx (col1));
INSERT INTO t1 VALUES (1),(2),(3),(4),(5),(6),(7),(8),(9),(10),
(11),(12),(13),(14),(15),(16),(17),(18),(19),(20);
EXPLAIN SELECT col1 AS field1, col1 AS field2
-FROM t1 GROUP BY field1, field2+0;;
+FROM t1 GROUP BY field1, field2;;
id select_type table type possible_keys key key_len ref rows Extra
-1 SIMPLE t1 index NULL idx 5 NULL 20 Using index; Using temporary; Using filesort
+1 SIMPLE t1 index NULL idx 5 NULL 20 Using index
FLUSH STATUS;
SELECT col1 AS field1, col1 AS field2
-FROM t1 GROUP BY field1, field2+0;;
+FROM t1 GROUP BY field1, field2;;
field1 field2
1 1
2 2
@@ -1986,7 +1986,7 @@ field1 field2
20 20
SHOW SESSION STATUS LIKE 'Sort_scan%';
Variable_name Value
-Sort_scan 1
+Sort_scan 0
EXPLAIN SELECT SQL_BIG_RESULT col1 AS field1, col1 AS field2
FROM t1 GROUP BY field1, field2;;
id select_type table type possible_keys key key_len ref rows Extra
@@ -2320,7 +2320,7 @@ a int,
b varchar(1),
KEY (b,a)
);
-INSERT INTO t1 VALUES (1,NULL),(0,'a');
+INSERT INTO t1 VALUES (1,NULL),(0,'a'),(1,NULL),(0,'a');
EXPLAIN SELECT SQL_BUFFER_RESULT MIN(a), b FROM t1 WHERE t1.b = 'a' GROUP BY b;
id select_type table type possible_keys key key_len ref rows Extra