database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-07-27 18:02:13 +03:00
Code Activity

Added test cases for preceding test

Browse Source 
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:
Monty
2022-10-04 16:16:06 +03:00
committed by Sergei Petrunia
parent eb68023c8e
commit 727491b72a
290 changed files with 10927 additions and 8874 deletions
Download Patch File Download Diff File Expand all files Collapse all files

80
mysql-test/main/explain_json.result
View File

@ -713,12 +713,11 @@ EXPLAIN
create table t2 like t1;
insert into t2 select * from t1;
explain format=json
select * from t1,t2 where t1.a in ( select a from t0);
select * from t1,t2 where t1.a in ( select seq+0 from seq_1_to_100);
EXPLAIN
{
"query_block": {
"select_id": 1,
"const_condition": "1",
"nested_loop": [
{
"table": {
@ -734,11 +733,12 @@ EXPLAIN
"access_type": "eq_ref",
"possible_keys": ["distinct_key"],
"key": "distinct_key",
"key_length": "4",
"used_key_parts": ["a"],
"key_length": "8",
"used_key_parts": ["seq+0"],
"ref": ["func"],
"rows": 1,
"filtered": 100,
"attached_condition": "t1.a = seq_1_to_100.seq + 0",
"materialized": {
"unique": 1,
"query_block": {
@ -746,10 +746,14 @@ EXPLAIN
"nested_loop": [
{
"table": {
"table_name": "t0",
"access_type": "ALL",
"rows": 10,
"filtered": 100
"table_name": "seq_1_to_100",
"access_type": "index",
"key": "PRIMARY",
"key_length": "8",
"used_key_parts": ["seq"],
"rows": 100,
"filtered": 100,
"using_index": true
}
}
]
@ -766,7 +770,7 @@ EXPLAIN
"filtered": 100
},
"buffer_type": "flat",
"buffer_size": "1Kb",
"buffer_size": "19Kb",
"join_type": "BNL"
}
}
@ -847,7 +851,7 @@ EXPLAIN
"table_name": "t1",
"access_type": "ALL",
"rows": 10,
"filtered": 100
"filtered": 10
},
"buffer_type": "flat",
"buffer_size": "206",
@ -1225,12 +1229,18 @@ analyze table t1;
Table Op Msg_type Msg_text
test.t1 analyze status Engine-independent statistics collected
test.t1 analyze status Table is already up to date
select count(*) from t1;
count(*)
128
explain select count(distinct a1,a2,b) from t1 where (a2 >= 'b') and (b = 'a');
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range NULL idx_t1_1 147 NULL 17 Using where; Using index for group-by
1 SIMPLE t1 range NULL idx_t1_2 147 NULL 17 Using where; Using index for group-by
explain select count(distinct a1,a2,b,c) from t1 where (a2 >= 'b') and (b = 'a') and (c = 'i121');
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range NULL idx_t1_1 163 NULL 65 Using where; Using index for group-by
1 SIMPLE t1 index NULL idx_t1_1 163 NULL 128 Using where; Using index
explain select count(distinct a1,a2,b) from t1 where a1 >= "" and (a2 >= 'b') and (b = 'a');
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range idx_t1_0,idx_t1_1,idx_t1_2 idx_t1_1 147 NULL 1 Using where; Using index for group-by
explain format=json select count(distinct a1,a2,b) from t1 where (a2 >= 'b') and (b = 'a');
EXPLAIN
{
@ -1241,7 +1251,7 @@ EXPLAIN
"table": {
"table_name": "t1",
"access_type": "range",
"key": "idx_t1_1",
"key": "idx_t1_2",
"key_length": "147",
"used_key_parts": ["a1", "a2", "b"],
"rows": 17,
@ -1262,13 +1272,36 @@ EXPLAIN
{
"table": {
"table_name": "t1",
"access_type": "range",
"access_type": "index",
"key": "idx_t1_1",
"key_length": "163",
"used_key_parts": ["a1", "a2", "b", "c"],
"rows": 65,
"filtered": 100,
"rows": 128,
"filtered": 0.198364258,
"attached_condition": "t1.b = 'a' and t1.c = 'i121' and t1.a2 >= 'b'",
"using_index": true
}
}
]
}
}
explain format=json select count(distinct a1,a2,b) from t1 where a1 >= "" and (a2 >= 'b') and (b = 'a');
EXPLAIN
{
"query_block": {
"select_id": 1,
"nested_loop": [
{
"table": {
"table_name": "t1",
"access_type": "range",
"possible_keys": ["idx_t1_0", "idx_t1_1", "idx_t1_2"],
"key": "idx_t1_1",
"key_length": "147",
"used_key_parts": ["a1", "a2", "b"],
"rows": 1,
"filtered": 100,
"attached_condition": "t1.b = 'a' and t1.a1 >= '' and t1.a2 >= 'b'",
"using_index_for_group_by": true
}
}
@ -1470,7 +1503,7 @@ insert into t2 values (1),(2);
explain
select * from t1 left join t2 on t2.pk > 10 and t2.pk < 0;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t2 const PRIMARY NULL NULL NULL 1 Impossible ON condition
1 SIMPLE t2 const PRIMARY NULL NULL NULL 0 Impossible ON condition
1 SIMPLE t1 ALL NULL NULL NULL NULL 2
explain format=json
select * from t1 left join t2 on t2.pk > 10 and t2.pk < 0;
@ -1485,8 +1518,8 @@ EXPLAIN
"table_name": "t2",
"access_type": "const",
"possible_keys": ["PRIMARY"],
"rows": 1,
"filtered": 100,
"rows": 0,
"filtered": 0,
"impossible_on_condition": true
}
},
@ -1520,9 +1553,9 @@ ANALYZE
"access_type": "const",
"possible_keys": ["PRIMARY"],
"r_loops": 0,
"rows": 1,
"rows": 0,
"r_rows": null,
"filtered": 100,
"filtered": 0,
"r_filtered": null,
"impossible_on_condition": true
}
@ -1832,7 +1865,8 @@ ANALYZE
"buffer_size": "400",
"join_type": "BKA",
"mrr_type": "Rowid-ordered scan",
"r_filtered": 100
"r_filtered": 100,
"r_unpack_time_ms": "REPLACED"
}
}
]
@ -2004,7 +2038,7 @@ EXPLAIN
"table_name": "t3",
"access_type": "ALL",
"rows": 2,
"filtered": 100
"filtered": 25
},
"buffer_type": "incremental",
"buffer_size": "109",