mirror of
https://github.com/MariaDB/server.git
synced 2025-07-30 16:24:05 +03:00
Added test cases for preceding test
This includes all test changes from "Changing all cost calculation to be given in milliseconds" and forwards. Some of the things that caused changes in the result files: - As part of fixing tests, I added 'echo' to some comments to be able to easier find out where things where wrong. - MATERIALIZED has now a higher cost compared to X than before. Because of this some MATERIALIZED types have changed to DEPENDEND SUBQUERY. - Some test cases that required MATERIALIZED to repeat a bug was changed by adding more rows to force MATERIALIZED to happen. - 'Filtered' in SHOW EXPLAIN has in many case changed from 100.00 to something smaller. This is because now filtered also takes into account the smallest possible ref access and filters, even if they where not used. Another reason for 'Filtered' being smaller is that we now also take into account implicit filtering done for subqueries using FIRSTMATCH. (main.subselect_no_exists_to_in) This is caluculated in best_access_path() and stored in records_out. - Table orders has changed because more accurate costs. - 'index' and 'ALL' for small tables has changed to use 'range' or 'ref' because of optimizer_scan_setup_cost. - index can be changed to 'range' as 'range' optimizer assumes we don't have to read the blocks from disk that range optimizer has already read. This can be confusing in the case where there is no obvious where clause but instead there is a hidden 'key_column > NULL' added by the optimizer. (main.subselect_no_exists_to_in) - Scan on primary clustered key does not report 'Using Index' anymore (It's a table scan, not an index scan). - For derived tables, the number of rows is now 100 instead of 2, which can be seen in EXPLAIN. - More tests have "Using index for group by" as the cost of this optimization is now more correct (lower). - A primary key could be preferred for a normal key, even if it would access more rows, as it's faster to do 1 lokoup and 3 'index_next' on a clustered primary key than one lookup trough a secondary. (main.stat_tables_innodb) Notes: - There was a 4.7% more calls to best_extension_by_limited_search() in the main.greedy_optimizer test. However examining the test results it looked that the plans where slightly better (eq_ref where more chained together) so I assume this is ok. - I have verified a few test cases where there was notable/unexpected changes in the plan and in all cases the new optimizer plans where faster. (main.greedy_optimizer and some others)
This commit is contained in:
@ -5,16 +5,13 @@
|
||||
select count(*) from lineitem where l_orderkey=130 and l_shipdate='1992-07-01';
|
||||
id select_type table type possible_keys key key_len ref rows Extra
|
||||
-1 SIMPLE lineitem ref PRIMARY,i_l_shipdate,i_l_orderkey,i_l_orderkey_quantity i_l_shipdate 8 const,const 1 Using index
|
||||
+1 SIMPLE lineitem index_merge PRIMARY,i_l_shipdate,i_l_orderkey,i_l_orderkey_quantity i_l_orderkey,i_l_shipdate 4,4 NULL 1 Using intersect(i_l_orderkey,i_l_shipdate); Using where; Using index
|
||||
+1 SIMPLE lineitem ref PRIMARY,i_l_shipdate,i_l_orderkey,i_l_orderkey_quantity i_l_shipdate 4 const 6 Using where; Using index
|
||||
flush status;
|
||||
select count(*) from lineitem where l_orderkey=130 and l_shipdate='1992-07-01';
|
||||
count(*)
|
||||
@@ -17,9 +17,9 @@
|
||||
show status like 'handler_read%';
|
||||
Variable_name Value
|
||||
@@ -19,7 +19,7 @@
|
||||
Handler_read_first 0
|
||||
-Handler_read_key 1
|
||||
+Handler_read_key 2
|
||||
Handler_read_key 1
|
||||
Handler_read_last 0
|
||||
-Handler_read_next 1
|
||||
+Handler_read_next 6
|
||||
@ -98,16 +95,13 @@
|
||||
where l_shipdate='1992-07-01' and l_orderkey=130;
|
||||
id select_type table type possible_keys key key_len ref rows Extra
|
||||
-1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Select tables optimized away
|
||||
+1 SIMPLE lineitem index_merge PRIMARY,i_l_shipdate,i_l_orderkey,i_l_orderkey_quantity i_l_orderkey,i_l_shipdate 4,4 NULL 1 Using intersect(i_l_orderkey,i_l_shipdate); Using where; Using index
|
||||
+1 SIMPLE lineitem ref PRIMARY,i_l_shipdate,i_l_orderkey,i_l_orderkey_quantity i_l_shipdate 4 const 6 Using where; Using index
|
||||
flush status;
|
||||
select max(l_linenumber) from lineitem
|
||||
where l_shipdate='1992-07-01' and l_orderkey=130;
|
||||
@@ -143,9 +143,9 @@
|
||||
show status like 'handler_read%';
|
||||
Variable_name Value
|
||||
@@ -145,7 +145,7 @@
|
||||
Handler_read_first 0
|
||||
-Handler_read_key 1
|
||||
+Handler_read_key 2
|
||||
Handler_read_key 1
|
||||
Handler_read_last 0
|
||||
-Handler_read_next 0
|
||||
+Handler_read_next 6
|
||||
@ -178,7 +172,7 @@
|
||||
where l_partkey between 1 and 10 group by l_partkey;
|
||||
id select_type table type possible_keys key key_len ref rows Extra
|
||||
-1 SIMPLE lineitem range i_l_suppkey_partkey,i_l_partkey i_l_partkey 5 NULL # Using where; Using index for group-by
|
||||
+1 SIMPLE lineitem range i_l_suppkey_partkey,i_l_partkey i_l_partkey 5 NULL # Using where; Using index
|
||||
+1 SIMPLE lineitem range i_l_suppkey_partkey,i_l_partkey i_l_suppkey_partkey 5 NULL # Using where; Using index
|
||||
flush status;
|
||||
select max(l_orderkey) from lineitem
|
||||
where l_partkey between 1 and 10 group by l_partkey;
|
||||
@ -236,17 +230,17 @@
|
||||
Handler_read_retry 0
|
||||
Handler_read_rnd 0
|
||||
@@ -314,8 +314,8 @@
|
||||
select * from t0, part ignore index (primary)
|
||||
select straight_join * from t0, part ignore index (primary)
|
||||
where p_partkey=t0.a and p_size=1;
|
||||
id select_type table type possible_keys key key_len ref rows Extra
|
||||
-1 SIMPLE t0 ALL NULL NULL NULL NULL 5 Using where
|
||||
-1 SIMPLE part eq_ref i_p_size i_p_size 9 const,dbt3_s001.t0.a 1
|
||||
+1 SIMPLE t0 ALL NULL NULL NULL NULL 5
|
||||
+1 SIMPLE part ref i_p_size i_p_size 5 const 5 Using index condition
|
||||
select * from t0, part ignore index (primary)
|
||||
select straight_join * from t0, part ignore index (primary)
|
||||
where p_partkey=t0.a and p_size=1;
|
||||
a p_partkey p_name p_mfgr p_brand p_type p_size p_container p_retailprice p_comment
|
||||
@@ -494,7 +494,7 @@
|
||||
@@ -495,7 +495,7 @@
|
||||
select * from t1, t3 where t3.col1=t1.a and t3.col2=t1.a and t3.pk1=t1.a;
|
||||
id select_type table type possible_keys key key_len ref rows Extra
|
||||
1 SIMPLE t1 ALL NULL NULL NULL NULL # Using where
|
||||
@ -255,7 +249,7 @@
|
||||
drop table t1,t2,t3;
|
||||
#
|
||||
# Bug mdev-4340: performance regression with extended_keys=on
|
||||
@@ -725,13 +725,13 @@
|
||||
@@ -726,13 +726,13 @@
|
||||
select * from t1 force index(index_date_updated)
|
||||
where index_date_updated= 10 and index_id < 800;
|
||||
id select_type table type possible_keys key key_len ref rows Extra
|
||||
@ -271,7 +265,7 @@
|
||||
drop table t0,t1,t2;
|
||||
#
|
||||
# MDEV-11196: Error:Run-Time Check Failure #2 - Stack around the variable 'key_buff'
|
||||
@@ -766,13 +766,14 @@
|
||||
@@ -769,11 +769,12 @@
|
||||
{
|
||||
"table": {
|
||||
"table_name": "t1",
|
||||
@ -285,12 +279,9 @@
|
||||
+ "used_key_parts": ["f2"],
|
||||
+ "ref": ["const"],
|
||||
"rows": 1,
|
||||
- "filtered": 50,
|
||||
+ "filtered": 100,
|
||||
"filtered": 100,
|
||||
"index_condition": "t1.pk1 <= 5 and t1.pk2 <= 5 and t1.f2 = 'abc'",
|
||||
"attached_condition": "t1.f1 <= '3'"
|
||||
}
|
||||
@@ -799,8 +800,8 @@
|
||||
@@ -806,8 +807,8 @@
|
||||
"access_type": "range",
|
||||
"possible_keys": ["k1"],
|
||||
"key": "k1",
|
||||
@ -299,5 +290,5 @@
|
||||
+ "key_length": "3007",
|
||||
+ "used_key_parts": ["pk1", "f2"],
|
||||
"rows": 1,
|
||||
"filtered": 50,
|
||||
"filtered": 100,
|
||||
"index_condition": "t1.f2 <= 5 and t1.pk2 <= 5 and t1.pk1 = 'abc'",
|
||||
|
Reference in New Issue
Block a user