that was mistakenly merged from mysql-5.5.47
This commit is contained in:
Sergei Golubchik 2015-12-09 21:22:37 +01:00
parent c19972fc87
commit 265e833fdd
2 changed files with 0 additions and 35 deletions

View file

@ -1748,27 +1748,6 @@ Item_in_subselect::single_value_transformer(JOIN *join)
runtime created Ref item which is deleted at the end
of the statement. Thus one of 'substitution' arguments
can be broken in case of PS.
@todo
Why do we use real_item()/substitutional_item() instead of the plain
left_expr?
Because left_expr might be a rollbackable item, and we fail to properly
rollback all copies of left_expr at end of execution, so we want to
avoid creating copies of left_expr as much as possible, so we use
real_item() instead.
Doing a proper rollback is difficult: the change was registered for the
original item which was the left argument of IN. Then this item was
copied to left_expr, which is copied below to substitution->args[0]. To
do a proper rollback, we would have to restore the content
of both copies as well as the original item. There might be more copies,
if AND items have been constructed.
The same applies to the right expression.
However, using real_item()/substitutional_item() brings its own
problems: for example, we lose information that the item is an outer
reference; the item can thus wrongly be considered for a Keyuse (causing
bug#17766653).
When WL#6570 removes the "rolling back" system, all
real_item()/substitutional_item() in this file should be removed.
*/
substitution= func->create(left_expr, where_item);
have_to_be_excluded= 1;
@ -2055,9 +2034,6 @@ Item_in_subselect::create_single_in_to_exists_cond(JOIN *join,
}
else
{
/*
Grep for "WL#6570" to see the relevant comment about real_item.
*/
Item *item= (Item*) select_lex->item_list.head()->real_item();
if (select_lex->table_list.elements)

View file

@ -4114,17 +4114,6 @@ add_key_field(JOIN *join,
Field *field, bool eq_func, Item **value, uint num_values,
table_map usable_tables, SARGABLE_PARAM **sargables)
{
if (field->table->reginfo.join_tab == NULL)
{
/*
Due to a bug in IN-to-EXISTS (grep for real_item() in item_subselect.cc
for more info), an index over a field from an outer query might be
considered here, which is incorrect. Their query has been fully
optimized already so their reginfo.join_tab is NULL and we reject them.
*/
return;
}
uint optimize= 0;
if (eq_func &&
((join->is_allowed_hash_join_access() &&