Skip to content
  • Neeraj Bisht's avatar
    dc9d0a3c
    Bug#16346367 : QUERY PROC RE-EXECUTE OF STORED ROUTINE, INEFFICIENT QUERY PLAN · dc9d0a3c
    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.
    dc9d0a3c
    Bug#16346367 : QUERY PROC RE-EXECUTE OF STORED ROUTINE, INEFFICIENT QUERY PLAN
    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.
Loading