|
The branch: bb-10.11-selectivity
Also making another review pass while doing this.
Findings
> commit a91f4f7d6e676644b349a63995ff8856e5081bce
|
> Author: Monty <monty@mariadb.org>
|
> Date: Mon Nov 1 12:34:24 2021 +0200
|
>
|
> Update row and key fetch cost models to take into account data copy costs
|
This change in table_elim.result exposes a bug:
@@ -562,10 +562,7 @@ LEFT JOIN t1 ON t4.f1 = t1.f1
|
JOIN t5 ON t4.f3 ON t3.f1 = t5.f5 ON t2.f4 = t3.f4
|
WHERE t3.f2 ;
|
id select_type table type possible_keys key key_len ref rows Extra
|
-1 SIMPLE t3 ALL NULL NULL NULL NULL 2 Using where
|
-1 SIMPLE t5 ref f5 f5 5 test.t3.f1 2 Using where; Using index
|
-1 SIMPLE t4 ALL NULL NULL NULL NULL 3 Using where
|
-1 SIMPLE t2 ALL f4 NULL NULL NULL 11 Using where; Using join buffer (flat, BNL join)
|
+1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const tables
|
# ^^ The above must not produce a QEP of t3,t5,t2,t4
|
# as that violates the "no interleaving of outer join nests" rule.
|
DROP TABLE t1,t2,t3,t4,t5;
|
table t5 has 0 rows, matching_candidates_in_table()=0 and the optimizer decides "Impossible WHERE" ?
(Before this patch, matching_candidates_in_table() would return 0, but it was not called because the optimizer didn't consider full scan on table t5)
|