bk commit into 5.2 tree (sergefp:1.2539)

Below is the list of changes that have just been committed into a local 5.2 repository of psergey. When psergey does a push these changes will be propagated to the main repository and, within 24 hours after the push, to the public repository.
For information on how to access the public repository see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html

ChangeSet@1.2539, 2007-06-30 20:28:30+04:00, sergefp@mysql.com +1 -0   Merge WL#2980 & WL#1110, Step 2

  sql/sql_select.cc@1.544, 2007-06-30 20:27:44+04:00, sergefp@mysql.com +42 -39     Merge WL#2980 & WL#1110, Step 2

# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: sergefp
# Host: pylon.mylan
# Root: /home/psergey/mysql-5.2-merge-12

• 1.543/sql/sql_select.cc 2007-06-30 20:28:36 +04:00 +++ 1.544/sql/sql_select.cc 2007-06-30 20:28:36 +04:00 @@ -583,6 +583,46 @@ else { fprintf(stderr, "subq is not an sj candidate\n"); + Item_in_subselect *in_subs= NULL; + + /* + Check if the subquery predicate can be executed via materialization. + The required conditions are: + 1. Subquery predicate is an IN/=ANY subq predicate + 2. Subquery is a single SELECT (not a UNION) + 3. Subquery is not a table-less query. In this case there is no + point in materializing. + 4. Subquery predicate is a top-level predicate + (this implies it is not negated) + TODO: this is a limitation that should be lifeted once we + implement correct NULL semantics (WL#3830) + 5. Subquery is non-correlated + TODO: + This is an overly restrictive condition. It can be extended to: + (Subquery is non-correlated || + Subquery is correlated to any query outer to IN predicate || + (Subquery is correlated to the immediate outer query && + Subquery !contains {GROUP BY, ORDER BY [LIMIT], + aggregate functions) && subquery predicate is not under "NOT IN")) + + (*) The subquery must be part of a SELECT statement. The current + condition also excludes multi-table update statements. + + We have to determine whether we will perform subquery materialization + before calling the IN=>EXISTS transformation, so that we know whether to + perform the whole transformation or only that part of it which wraps + Item_in_subselect in an Item_in_optimizer. + */ + if (subselect->substype() == Item_subselect::IN_SUBS && // 1 + !select_lex->master_unit()->first_select()->next_select() && // 2 + select_lex->master_unit()->first_select()->leaf_tables && // 3 + thd->lex->sql_command == SQLCOM_SELECT) // * + { + in_subs= (Item_in_subselect*) subselect; + in_subs->use_hash_sj= (in_subs->is_top_level_item() && // 4 + !in_subs->is_correlated); // 5 + } + if ((res= subselect->select_transformer(this)) != Item_subselect::RES_OK) { @@ -590,46 +630,8 @@ DBUG_RETURN((res == Item_subselect::RES_ERROR)); } //psergey-merge: todo: VV +#if 0 Item_subselect::trans_res trans_res; - Item_in_subselect *in_subs= NULL; - - /* - Check if the subquery predicate can be executed via materialization. - The required conditions are: - 1. Subquery predicate is an IN/=ANY subq predicate - 2. Subquery is a single SELECT (not a UNION) - 3. Subquery is not a table-less query. In this case there is no - point in materializing. - 4. Subquery predicate is a top-level predicate - (this implies it is not negated) - TODO: this is a limitation that should be lifeted once we - implement correct NULL semantics (WL#3830) - 5. Subquery is non-correlated - TODO: - This is an overly restrictive condition. It can be extended to: - (Subquery is non-correlated || - Subquery is correlated to any query outer to IN predicate || - (Subquery is correlated to the immediate outer query && - Subquery !contains {GROUP BY, ORDER BY [LIMIT], - aggregate functions) && subquery predicate is not under "NOT IN")) - - (*) The subquery must be part of a SELECT statement. The current - condition also excludes multi-table update statements. - - We have to determine whether we will perform subquery materialization - before calling the IN=>EXISTS transformation, so that we know whether to - perform the whole transformation or only that part of it which wraps - Item_in_subselect in an Item_in_optimizer. - */ - if (subselect->substype() == Item_subselect::IN_SUBS && // 1 - !select_lex->master_unit()->first_select()->next_select() && // 2 - select_lex->master_unit()->first_select()->leaf_tables && // 3 - thd->lex->sql_command == SQLCOM_SELECT) // * - { - in_subs= (Item_in_subselect*) subselect; - in_subs->use_hash_sj= (in_subs->is_top_level_item() && // 4 - !in_subs->is_correlated); // 5 - }

       /*
         For IN predicates, if Item_in_subselect::use_hash_sj == TRUE,
@@ -641,6 +643,7 @@
         select_lex->fix_prepare_information(thd, &conds, &having);
 	DBUG_RETURN((trans_res == Item_subselect::RES_ERROR));
       }
+#endif      
     }

-- 
MySQL Code Commits Mailing List
For list archives: 
http://lists.mysql.com/commits
To unsubscribe:    
http://lists.mysql.com/commits?unsub=lists@pantek.com