table resolution".
Added members to Item_ident for storing original db, table and field
names since those that set later from Field have shorter life-time
than required by prep. stmt. So we need to restore original names in
Item_ident::cleanup(). Also now using special construnctor for creation
of Item_field from Field object that ensures that table and field name
have big enough life-time.
"Fix" for bug #2050 "10 to 1 performance drop with server 4.1.1"
Clean ups in implementation of caching of field number in table.
Added caching of table in which field is found in find_field_in_tables().
This is to enable table handlers to implement online create/drop index.
It consists of some parts:
- New default handler methods in handler.h
- Split of mysql_alter_table. It decides if only one kind of
alteration is to be done (e.g. only create indexes or only drop
indexes etc.) It then calls the specialized new handler method if
the handler implements it. Otherwise it calls real_alter_table.
- The parser sets flags for each alter operation detected in a
command. These are used by mysql_alter_table for the decision.
- mysql_prepare_table is pulled out of mysql_create_table. This is
also used by mysql_create_index to prepare the key structure array
for the handler. It is also used by mysql_create_index and
mysql_drop_index to prepare a call to mysql_create_frm.
- mysql_create_frm is pulled out of rea_create_table for use by
mysql_create_index and mysql_drop_index after the index is
created/dropped.
Thanks to Antony who supplied most of the changes.
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.
this is better in this case:
- imagine user1 has created a temp table
- imagine user2 does FLUSH TABLES WITH READ LOCK, then takes a backup,
then RESET MASTER then UNLOCK TABLES, like mysqldump --first-slave
- then in the binlog you will finally have the DROP TEMPORARY TABLE,
but not the CREATE TEMPORARY TABLE, so when you later restore with
mysqlbinlog|mysql, mysql will complain that table does not exist.
Replication was already protected of this (it processes DROP TEMPORARY
TABLE as if there was a IF EXISTS), now I add it directly to the query
for mysqlbinlog|mysql to work.
even if the thread was killed, we write the DROP with error_code=0.
This will remove unneeded stops on slave, and will lose nothing:
if a real update was killed, this real update will be logged with the
nonzero error code and will cause the stop on slave.
when we open the HEAP table for the first time since server restart,
in hp_open(), we set a flag to propagate this info to the handler level
which then writes a DELETE FROM this_heap_table to the binlog.
It is not a perfect solution for the bug, because between the server start and
the first open of the table, the slave still had old data in his table so
a SELECT on the slave may show wrong content. But if there is a --init-file
to populate the HEAP table on master as startup, then this is a safe fix
(I'll put a note about init-file in the HEAP section of the manual).
