From 272e5e621265d8dfd3ca52af8a830c2d00955542 Mon Sep 17 00:00:00 2001 From: Igor Babaev Date: Wed, 23 Feb 2011 22:23:12 -0800 Subject: BNLH algorithm always used a full table scan over the joined table even in the cases when there existed range/index-merge scans that were cheaper than the full table scan. This was a defect/bug of the implementation of mwl #128. Now hash join can work not only with full table scan of the joined table, but also with full index scan, range and index-merge scans. Accordingly, in the cases when hash join is used the column 'type' in the EXPLAINs can contain now 'hash_ALL', 'hash_index', 'hash_range' and 'hash_index_merge'. If hash join is coupled with a range/index_merge scan then the columns 'key' and 'key_len' contain info not only on the used hash index, but also on the indexes used for the scan. --- sql/sql_select.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'sql/sql_select.h') diff --git a/sql/sql_select.h b/sql/sql_select.h index 4b5c69077a5..8a6a75cb80a 100644 --- a/sql/sql_select.h +++ b/sql/sql_select.h @@ -135,7 +135,7 @@ typedef struct st_table_ref enum join_type { JT_UNKNOWN,JT_SYSTEM,JT_CONST,JT_EQ_REF,JT_REF,JT_MAYBE_REF, JT_ALL, JT_RANGE, JT_NEXT, JT_FT, JT_REF_OR_NULL, JT_UNIQUE_SUBQUERY, JT_INDEX_SUBQUERY, JT_INDEX_MERGE, - JT_HASH}; + JT_HASH, JT_HASH_RANGE, JT_HASH_NEXT, JT_HASH_INDEX_MERGE}; class JOIN; -- cgit v1.2.1