• unknown's avatar
    "Fix" for BUG #2050 "10 to 1 performance drop with server 4.1.1". · f6a8ec5f
    unknown authored
    Actually it is not a bug but right behavior observed as pefomance 
    degradation after we have forced Item_field::fix_fields() to 
    re-execute each time when we are executing prep stmt.
    
    This patch implements small optimization which heals this bad 
    behavior. We are caching field position in TABLE::field array in
    Item's member and are using this position for speeding up field
    lookups in fix_fields() in case of its re-execution.
    
    
    sql/item.cc:
      Added cached_field_index member to Item_ident for caching field
      position in TABLE::field array for quicker field lookup in case 
      fix_fields() is executed twice.
    sql/item.h:
      Added cached_field_index member to Item_ident for caching field
      position in TABLE::field array for quicker field lookup in case 
      fix_fields() is executed twice.
    sql/mysql_priv.h:
      Now find_field_in_table has one more in-out parameter which is used
      for caching field index in TABLE::field array stored for quicker
      field look up.
    sql/sql_acl.cc:
      Now find_field_in_table has one more in-out parameter which is used
      for caching field index in TABLE::field array stored for quicker
      field look up.
    sql/sql_base.cc:
      Optimization: Now when we are looking up Field by its name we are 
      caching its position in TABLE::field array in Item_ident::cached_field_index,
      so when we will call fix_fields() second time for this item (e.g.
      when we are re-executing prep statement) we can reuse this index
      to speed up this lookup.
    sql/table.cc:
      Now we storing in TABLE::name_hash pointers to elements of 
      TABLE::field array, because this allows easily retrieve index
      of field in this array when it is looked up by its name.
    sql/table.h:
      Added comment claryfying what we store in TABLE::name_hash.
    BitKeeper/etc/logging_ok:
      Logging to logging@openlogging.org accepted
    f6a8ec5f
logging_ok 3.57 KB