Allow firstmatch to use HASH joins

Firstmatch_picker::check_qep() has an optimization that allows firstmatch
to be used together with join buffer under some conditions. In this
case the cost was assumed to be same as what best_access_path()
had calculated.

However if HASH+join_buffer was used, then
fix_semijoin_strategies_for_picked_join_order() would remove the
join_buffer (which would cause a full join to be used) and the cost
assumption by Firstmatch_picker::check_qep() would be wrong.
Later check_join_cache_usage() sees that it's a full scan and decides
it can use join buffering, (But not the hash join).

Fixed by also allowing HASH joins with firstmatch.
This removes the need to change disable and re-enable join buffer.

Test case changes:
- HASH join used with firstmatch (Using join buffer (flat, BNLH join))
- Filtered could change with firstmatch as the conversion with and without
  join_buffered lost the filtering information.
- The not "re-enabling join buffer" is shown in main.optimizer_trace

Original code by Sergei, optimized by Monty.

Author: Sergei Petrunia <sergey@mariadb.com>, monty@mariadb.org

1 files changed, 1 insertions, 1 deletions

diff --git a/mysql-test/suite/optimizer_unfixed_bugs/r/bug45221.result b/mysql-test/suite/optimizer_unfixed_bugs/r/bug45221.result
index 17edbc19e0e..79100ca2b48 100644
--- a/mysql-test/suite/optimizer_unfixed_bugs/r/bug45221.result
+++ b/mysql-test/suite/optimizer_unfixed_bugs/r/bug45221.result
@@ -29,10 +29,10 @@ SELECT `int_key`
 FROM t2  
 WHERE `date_nokey`  < `datetime_nokey`  XOR OUTR .`date_nokey`  )   ;
 pk
+9
 2
 5
 6
-9
 SELECT `pk`  
 FROM t1  
 WHERE `pk`  IN (