Merge

mysql-test/r/derived_opt.result

@@ -358,25 +358,25 @@ drop table t1, t2, t3, t4;
 create table t1(a int);
 insert into t1 values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9);
 create table t2 (a int, b int, c text);
-insert into t2 
-select 
+insert into t2
+select
 A.a + B.a* 10,
 A.a + B.a* 10,
-'blob-data' 
+'blob-data'
 from t1 A, t1 B;
 set @tmp_jcl= @@join_cache_level;
 set @tmp_os= @@optimizer_switch;
 set join_cache_level=6;
 set @@optimizer_switch='derived_merge=on,derived_with_keys=on,mrr=on';
-explain 
-select * from 
+explain
+select * from
 t1 join
-(select * from t2 order by a limit 1000) as D1 
-where 
+(select * from t2 order by a limit 1000) as D1
+where
 D1.a= t1.a;
 id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
 1	PRIMARY	t1	ALL	NULL	NULL	NULL	NULL	10	Using where
-1	PRIMARY	<derived2>	ref	key0	key0	5	test.t1.a	10	
+1	PRIMARY	<derived2>	hash_ALL	key0	#hash#key0	5	test.t1.a	100	Using join buffer (flat, BNLH join)
 2	DERIVED	t2	ALL	NULL	NULL	NULL	NULL	100	Using filesort
 set join_cache_level=@tmp_jcl;
 set optimizer_switch=@tmp_os;

mysql-test/t/derived_opt.test

@@ -279,22 +279,22 @@ create table t1(a int);
 insert into t1 values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9);
 
 create table t2 (a int, b int, c text);
-insert into t2 
-select 
+insert into t2
+select
   A.a + B.a* 10,
   A.a + B.a* 10,
-  'blob-data' 
+  'blob-data'
 from t1 A, t1 B;
 
 set @tmp_jcl= @@join_cache_level;
 set @tmp_os= @@optimizer_switch;
 set join_cache_level=6;
 set @@optimizer_switch='derived_merge=on,derived_with_keys=on,mrr=on';
-explain 
-select * from 
+explain
+select * from
   t1 join
-  (select * from t2 order by a limit 1000) as D1 
-where 
+  (select * from t2 order by a limit 1000) as D1
+where
   D1.a= t1.a;
 
 set join_cache_level=@tmp_jcl;

sql/sql_select.cc

@@ -10549,6 +10549,19 @@ uint check_join_cache_usage(JOIN_TAB *tab,
       cache_level--;
   }
     
+  /*
+    Don't use BKA for materialized tables. We could actually have a
+    meaningful use of BKA when linked join buffers are used.
+
+    The problem is, the temp.table is not filled (actually not even opened
+    properly) yet, and this doesn't let us call
+    handler->multi_range_read_info(). It is possible to come up with
+    estimates, etc. without acessing the table, but it seems not to worth the
+    effort now.
+  */
+  if (tab->table->pos_in_table_list->is_materialized_derived())
+    no_bka_cache= true;
+
   /*
     Don't use join buffering if we're dictated not to by no_jbuf_after
     (This is not meaningfully used currently)
@@ -10614,21 +10627,8 @@ uint check_join_cache_usage(JOIN_TAB *tab,
       goto no_join_cache;
     if (tab->ref.is_access_triggered())
       goto no_join_cache;
-    
-    /*
-      Don't use BKA for materialized tables. We could actually have a
-      meaningful use of BKA when linked join buffers are used.
-
-      The problem is, the temp.table is not filled (actually not even opened
-      properly) yet, and this doesn't let us call 
-      handler->multi_range_read_info(). It is possible to come up with
-      estimates, etc. without acessing the table, but it seems not to worth the
-      effort now.
-    */
-    if (tab->table->pos_in_table_list->is_materialized_derived())
-      goto no_join_cache;
 
-    if (!tab->is_ref_for_hash_join())
+    if (!tab->is_ref_for_hash_join() && !no_bka_cache)
     {
       flags= HA_MRR_NO_NULL_ENDPOINTS | HA_MRR_SINGLE_POINT;
       if (tab->table->covering_keys.is_set(tab->ref.key))