Commit 8b7c0d69 authored by Monty's avatar Monty Committed by Sergei Petrunia

In best_access_path() change record_count to 1.0 if its less than 1.0.

In essence this means that we expect the user query to have at least
one matching row in the end.
This change will not affect the estimated rows for the plan, but will
ensure that the cost for adding a table is not neglected because of
record count being too low.

The reasons for this is that if we have table combination that
together has a very high selectivity then join record_count could
become very low (close to 0)

This would cause costs for all future tables to be so small that they
are irrelevant for the rest of the plan.
This has been shown to be the case in some performance benchmarks and
in a few mtr tests.

There is also still a problem in selectivity calculations as joining two
tables in different order causes a different estimation of total rows.
This can be seen in selectivity_innodb.test, test 'Q20' where joining
nation,supplier is expecting 1.111 rows_out while joining supplier,nation
is expecting 0.04 rows_out.

The reason for 0.04 is that the optimizer estimates 'supplier' to have
10 matching rows, and joining with nation (eq_ref) has 1 row. However
selectivity of n_name = 'UNITED STATES' makes the optimizer things
that there will be only 0.04 matching rows.

This patch avoids this "too low row count" to affect cost
caclulations.
parent 02f6ba57
......@@ -265,7 +265,7 @@
drop table t0,t1,t2;
#
# MDEV-11196: Error:Run-Time Check Failure #2 - Stack around the variable 'key_buff'
@@ -770,12 +770,13 @@
@@ -770,11 +770,12 @@
{
"table": {
"table_name": "t1",
......@@ -281,8 +281,7 @@
"loops": 1,
"rows": 1,
"cost": "COST_REPLACED",
"filtered": 100,
@@ -809,9 +810,9 @@
@@ -810,8 +811,8 @@
"access_type": "range",
"possible_keys": ["k1"],
"key": "k1",
......@@ -293,4 +292,3 @@
"loops": 1,
"rows": 1,
"cost": "COST_REPLACED",
"filtered": 100,
......@@ -2813,7 +2813,7 @@ EXPLAIN
"key_length": "5",
"used_key_parts": ["a"],
"ref": ["test.t2.d"],
"loops": 0.471153846,
"loops": 1,
"rows": 11,
"cost": "COST_REPLACED",
"filtered": 100
......
......@@ -2798,7 +2798,7 @@ EXPLAIN
"key_length": "5",
"used_key_parts": ["a"],
"ref": ["test.t2.d"],
"loops": 0.471153846,
"loops": 1,
"rows": 11,
"cost": "COST_REPLACED",
"filtered": 100
......
......@@ -1455,7 +1455,7 @@ EXPLAIN
"key_length": "4",
"used_key_parts": ["o_orderkey"],
"ref": ["dbt3_s001.lineitem.l_orderkey"],
"loops": 0.101915071,
"loops": 1,
"rows": 1,
"cost": "COST_REPLACED",
"filtered": 7.466666698,
......@@ -1527,7 +1527,7 @@ ANALYZE
"key_length": "4",
"used_key_parts": ["o_orderkey"],
"ref": ["dbt3_s001.lineitem.l_orderkey"],
"loops": 0.101915071,
"loops": 1,
"r_loops": 7,
"rows": 1,
"r_rows": 1,
......@@ -1602,7 +1602,7 @@ EXPLAIN
"key_length": "4",
"used_key_parts": ["o_orderkey"],
"ref": ["dbt3_s001.lineitem.l_orderkey"],
"loops": 0.101915071,
"loops": 1,
"rows": 1,
"cost": "COST_REPLACED",
"filtered": 7.466666698,
......@@ -1674,7 +1674,7 @@ ANALYZE
"key_length": "4",
"used_key_parts": ["o_orderkey"],
"ref": ["dbt3_s001.lineitem.l_orderkey"],
"loops": 0.101915071,
"loops": 1,
"r_loops": 7,
"rows": 1,
"r_rows": 1,
......@@ -2080,7 +2080,7 @@ EXPLAIN
"key_length": "4",
"used_key_parts": ["l_orderkey"],
"ref": ["dbt3_s001.orders.o_orderkey"],
"loops": 0.760448,
"loops": 1,
"rows": 4,
"cost": "REPLACED",
"filtered": "REPLACED",
......@@ -2156,7 +2156,7 @@ ANALYZE
"key_length": "4",
"used_key_parts": ["l_orderkey"],
"ref": ["dbt3_s001.orders.o_orderkey"],
"loops": 0.760448,
"loops": 1,
"r_loops": 1,
"rows": 4,
"r_rows": 6,
......@@ -2238,7 +2238,7 @@ EXPLAIN
"key_length": "4",
"used_key_parts": ["l_orderkey"],
"ref": ["dbt3_s001.orders.o_orderkey"],
"loops": 0.760448,
"loops": 1,
"rows": 4,
"cost": "REPLACED",
"filtered": "REPLACED",
......@@ -2314,7 +2314,7 @@ ANALYZE
"key_length": "4",
"used_key_parts": ["l_orderkey"],
"ref": ["dbt3_s001.orders.o_orderkey"],
"loops": 0.760448,
"loops": 1,
"r_loops": 1,
"rows": 4,
"r_rows": 6,
......
......@@ -1456,7 +1456,7 @@ EXPLAIN
"key_length": "4",
"used_key_parts": ["o_orderkey"],
"ref": ["dbt3_s001.lineitem.l_orderkey"],
"loops": 0.090591174,
"loops": 1,
"rows": 1,
"cost": "COST_REPLACED",
"filtered": 8.466666222,
......@@ -1528,7 +1528,7 @@ ANALYZE
"key_length": "4",
"used_key_parts": ["o_orderkey"],
"ref": ["dbt3_s001.lineitem.l_orderkey"],
"loops": 0.090591174,
"loops": 1,
"r_loops": 7,
"rows": 1,
"r_rows": 1,
......@@ -1603,7 +1603,7 @@ EXPLAIN
"key_length": "4",
"used_key_parts": ["o_orderkey"],
"ref": ["dbt3_s001.lineitem.l_orderkey"],
"loops": 0.090591174,
"loops": 1,
"rows": 1,
"cost": "COST_REPLACED",
"filtered": 8.466666222,
......@@ -1675,7 +1675,7 @@ ANALYZE
"key_length": "4",
"used_key_parts": ["o_orderkey"],
"ref": ["dbt3_s001.lineitem.l_orderkey"],
"loops": 0.090591174,
"loops": 1,
"r_loops": 7,
"rows": 1,
"r_rows": 1,
......
......@@ -1403,7 +1403,7 @@ EXPLAIN
"key_length": "4",
"used_key_parts": ["o_orderkey"],
"ref": ["dbt3_s001.lineitem.l_orderkey"],
"loops": 0.101915071,
"loops": 1,
"rows": 1,
"cost": "COST_REPLACED",
"filtered": 5.666666508,
......@@ -1475,7 +1475,7 @@ ANALYZE
"key_length": "4",
"used_key_parts": ["o_orderkey"],
"ref": ["dbt3_s001.lineitem.l_orderkey"],
"loops": 0.101915071,
"loops": 1,
"r_loops": 7,
"rows": 1,
"r_rows": 1,
......@@ -1550,7 +1550,7 @@ EXPLAIN
"key_length": "4",
"used_key_parts": ["o_orderkey"],
"ref": ["dbt3_s001.lineitem.l_orderkey"],
"loops": 0.101915071,
"loops": 1,
"rows": 1,
"cost": "COST_REPLACED",
"filtered": 5.666666508,
......@@ -1622,7 +1622,7 @@ ANALYZE
"key_length": "4",
"used_key_parts": ["o_orderkey"],
"ref": ["dbt3_s001.lineitem.l_orderkey"],
"loops": 0.101915071,
"loops": 1,
"r_loops": 7,
"rows": 1,
"r_rows": 1,
......@@ -2007,7 +2007,7 @@ EXPLAIN
"key_length": "4",
"used_key_parts": ["l_orderkey"],
"ref": ["dbt3_s001.orders.o_orderkey"],
"loops": 0.849155556,
"loops": 1,
"rows": 4,
"cost": "REPLACED",
"filtered": "REPLACED",
......@@ -2083,7 +2083,7 @@ ANALYZE
"key_length": "4",
"used_key_parts": ["l_orderkey"],
"ref": ["dbt3_s001.orders.o_orderkey"],
"loops": 0.849155556,
"loops": 1,
"r_loops": 1,
"rows": 4,
"r_rows": 6,
......@@ -2165,7 +2165,7 @@ EXPLAIN
"key_length": "4",
"used_key_parts": ["l_orderkey"],
"ref": ["dbt3_s001.orders.o_orderkey"],
"loops": 0.849155556,
"loops": 1,
"rows": 4,
"cost": "REPLACED",
"filtered": "REPLACED",
......@@ -2241,7 +2241,7 @@ ANALYZE
"key_length": "4",
"used_key_parts": ["l_orderkey"],
"ref": ["dbt3_s001.orders.o_orderkey"],
"loops": 0.849155556,
"loops": 1,
"r_loops": 1,
"rows": 4,
"r_rows": 6,
......
This diff is collapsed.
......@@ -2499,9 +2499,9 @@ SELECT * FROM t1, t2
WHERE t1.a = t2.a AND t2.a IN (SELECT b FROM t3 STRAIGHT_JOIN t4);
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t3 system NULL NULL NULL NULL 1
1 PRIMARY t2 ref a a 5 const 1 Using index
1 PRIMARY t1 ref a a 5 const 1 Using index
1 PRIMARY t2 ref a a 5 func 1 Using index
1 PRIMARY t4 ALL NULL NULL NULL NULL 0 FirstMatch(t2); Using join buffer (flat, BNL join)
1 PRIMARY t1 ref a a 5 func 1 Using index
SELECT * FROM t1, t2
WHERE t1.a = t2.a AND t2.a IN (SELECT b FROM t3 STRAIGHT_JOIN t4);
a a
......
......@@ -2505,9 +2505,9 @@ SELECT * FROM t1, t2
WHERE t1.a = t2.a AND t2.a IN (SELECT b FROM t3 STRAIGHT_JOIN t4);
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t3 system NULL NULL NULL NULL 1
1 PRIMARY t2 ref a a 5 const 1 Using index
1 PRIMARY t1 ref a a 5 const 1 Using index
1 PRIMARY t2 ref a a 5 func 1 Using index
1 PRIMARY t4 ALL NULL NULL NULL NULL 0 FirstMatch(t2); Using join buffer (flat, BNL join)
1 PRIMARY t1 ref a a 5 func 1 Using index
SELECT * FROM t1, t2
WHERE t1.a = t2.a AND t2.a IN (SELECT b FROM t3 STRAIGHT_JOIN t4);
a a
......
......@@ -8101,6 +8101,14 @@ best_access_path(JOIN *join,
Json_writer_object trace_wrapper(thd, "best_access_path");
DBUG_ENTER("best_access_path");
/*
Assume that there is at least one accepted row from previous table combinations.
This fixes a problem when the selectivity for the preceding table combinations
becomes so high that record_count becomes << 1.0, which makes the cost for the
current table so low that it does not matter when calculating the best plans.
*/
set_if_bigger(record_count, 1.0);
best.cost= DBL_MAX;
best.records= DBL_MAX;
best.records_read= DBL_MAX;
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment