-
Neeraj Bisht authored
Problem:- In derived tables implementation, We only get to use indexes on derived tables on the first execution of a procedure and in later execution we are not able to use indexes. Analysis:- In case of derived tables, we call add_key_field() to add new fake keys for range optimizer. To choose the best key to read data. After creating the actual keys from this fake keys. We set the variable in TABLE_LIST::derived_keys_ready, to show that actual keys are created. This table_list is maintained in the memory after our exection is completed. So when we call our procedure second time, this TABLE_LIST::derived_keys_ready is already set and we assume that actual keys are already being created, but we will not find any key, which cause change in query execution plan. Solution:- Reset the TABLE_LIST::derived_keys_ready at the time JOIN_TAB::cleanup.
Neeraj Bisht authoredProblem:- In derived tables implementation, We only get to use indexes on derived tables on the first execution of a procedure and in later execution we are not able to use indexes. Analysis:- In case of derived tables, we call add_key_field() to add new fake keys for range optimizer. To choose the best key to read data. After creating the actual keys from this fake keys. We set the variable in TABLE_LIST::derived_keys_ready, to show that actual keys are created. This table_list is maintained in the memory after our exection is completed. So when we call our procedure second time, this TABLE_LIST::derived_keys_ready is already set and we assume that actual keys are already being created, but we will not find any key, which cause change in query execution plan. Solution:- Reset the TABLE_LIST::derived_keys_ready at the time JOIN_TAB::cleanup.
Loading