Hello Igor, On Thu, Jul 01, 2010 at 11:55:58PM -0700, Igor Babaev wrote:
According to our agreement I introduced a new flag for MRR. I called it HA_MRR_MATERIALIZED_KEYS. This flag passed to any MMR interface function that takes mrr_mode as a parameter says: key values used in ranges are materialized in some buffers external to MRR.
This patch only gives DS-MRR information that the keys are materialized. However, DS-MRR needs to work on (key, range_id) pairs. The patch doesn't allow to assoicate key with range_id (or vice versa), so DS-MRR will have to keep (key_pointer, range_id) tuples. If we consider 64-bit environment, then sizeof(key_value_pointer)== sizeof(key_value), and this patch won't bring any benefit at all. I was expecting that the patch will provide some means to associate key_value_pointer with range_id, so that DS-MRR won't need to store both. Can we discuss this on scrum meeting or Monday evening?
=== modified file 'sql/handler.h' --- sql/handler.h 2010-03-20 12:01:47 +0000 +++ sql/handler.h 2010-07-01 20:00:35 +0000 @@ -1212,6 +1212,12 @@ void get_sweep_read_cost(TABLE *table, h */ #define HA_MRR_NO_NULL_ENDPOINTS 128
+/* + The MRR user has materialized range keys somewhere in the user's buffer. + This can be used for optimization of the procedure that sorts these keys + since in this case key values don't have to be copied into the MRR buffer. +*/ +#define HA_MRR_MATERIALIZED_KEYS 256
/*
=== modified file 'sql/sql_join_cache.cc' --- sql/sql_join_cache.cc 2010-03-07 15:41:45 +0000 +++ sql/sql_join_cache.cc 2010-07-01 19:59:55 +0000 @@ -651,6 +651,9 @@ int JOIN_CACHE_BKA::init()
use_emb_key= check_emb_key_usage();
+ if (use_emb_key) + mrr_mode|= HA_MRR_MATERIALIZED_KEYS; + create_remaining_fields(FALSE);
set_constants(); @@ -2617,6 +2620,8 @@ int JOIN_CACHE_BKA_UNIQUE::init() data_fields_offset+= copy->length; }
+ mrr_mode|= HA_MRR_MATERIALIZED_KEYS; + DBUG_RETURN(rc); }
BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog