Merged the fix for bug lp:944706, mdev-193

1 files changed, 42 insertions, 0 deletions

diff --git a/sql/item_subselect.cc b/sql/item_subselect.cc
index 9a3f5bd8a51..4a8e1393a22 100644
--- a/sql/item_subselect.cc
+++ b/sql/item_subselect.cc
@@ -523,6 +523,48 @@ void Item_subselect::recalc_used_tables(st_select_lex *new_parent,
   */
 }
 
+
+/**
+  Determine if a subquery is expensive to execute during query optimization.
+
+  @details The cost of execution of a subquery is estimated based on an
+  estimate of the number of rows the subquery will access during execution.
+  This measure is used instead of JOIN::read_time, because it is considered
+  to be much more reliable than the cost estimate.
+
+  @return true if the subquery is expensive
+  @return false otherwise
+*/
+bool Item_subselect::is_expensive()
+{
+  double examined_rows= 0;
+
+  for (SELECT_LEX *sl= unit->first_select(); sl; sl= sl->next_select())
+  {
+    JOIN *cur_join= sl->join;
+    if (!cur_join)
+      continue;
+
+    /* If a subquery is not optimized we cannot estimate its cost. */
+    if (!cur_join->join_tab)
+      return true;
+
+    if (sl->first_inner_unit())
+    {
+      /*
+        Subqueries that contain subqueries are considered expensive.
+        @todo: accumulate the cost of subqueries.
+      */
+      return true;
+    }
+
+    examined_rows+= cur_join->get_examined_rows();
+  }
+
+  return (examined_rows > thd->variables.expensive_subquery_limit);
+}
+
+
 bool Item_subselect::walk(Item_processor processor, bool walk_subquery,
                           uchar *argument)
 {