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;
   }