PKGBUILDs/extra/mariadb/0007-MDEV-20646.patch
2019-11-26 13:37:46 +00:00

45 lines
1.9 KiB
Diff

commit d4edb0510ec1189f65850bb47977e94ed98b1f71
Author: Sergei Petrunia <psergey@askmonty.org>
Date: Wed Nov 13 18:53:59 2019 +0300
MDEV-20646: 10.3.18 is slower than 10.3.17
Fix incorrect change introduced in the fix for MDEV-20109.
The patch tried to compute a more precise estimate for the record_count
value in SJ-Materialization-Scan strategy (in
Sj_materialization_picker::check_qep). However the new formula is worse
as it produces extremely optimistic results in common cases where
SJ-Materialization-Scan should be used)
The old formula produces pessimistic results in cases when Sj-Materialization-
Scan is unlikely to be a good choice anyway. So, the old behavior is better.
diff --git a/sql/opt_subselect.cc b/sql/opt_subselect.cc
index aeafc13998a..a8afd952a4d 100644
--- a/sql/opt_subselect.cc
+++ b/sql/opt_subselect.cc
@@ -3029,7 +3029,22 @@ bool Sj_materialization_picker::check_qep(JOIN *join,
*strategy= SJ_OPT_MATERIALIZE_SCAN;
*read_time= prefix_cost;
- *record_count= prefix_rec_count / mat_info->rows_with_duplicates;
+ /*
+ Note: the next line means we did not remove the subquery's fanout from
+ *record_count. It needs to be removed, as the join prefix is
+
+ ntX SJM-SCAN(it1 ... itN) | (ot1 ... otN) ...
+
+ here, the SJM-SCAN may have introduced subquery's fanout (duplicate rows,
+ rows that don't have matches in ot1_i). All this fanout is gone after
+ table otN (or earlier) but taking it into account is hard.
+
+ Some consolation here is that SJM-Scan strategy is applicable when the
+ subquery is smaller than tables otX. If the subquery has large cardinality,
+ we can greatly overestimate *record_count here, but it doesn't matter as
+ SJ-Materialization-Lookup is a better strategy anyway.
+ */
+ *record_count= prefix_rec_count;
*handled_fanout= mat_nest->sj_inner_tables;
return TRUE;
}