bk commit into 4.1 tree (gkodinov:1.2531)

[gkodinov]

Below is the list of changes that have just been committed into a local
4.1 repository of gkodinov. When gkodinov 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@stripped, 2006-10-19 14:34:56+02:00, gkodinov@stripped +1 -0
  Merge dl145s.mysql.com:/data/bk/team_tree_merge/mysql-4.1
  into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-4.1-opt
  MERGE: 1.2522.53.4

  sql/sql_select.cc@stripped, 2006-10-19 14:34:54+02:00, gkodinov@stripped +0 -0
    Auto merged
    MERGE: 1.459.1.1

# 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:	gkodinov
# Host:	dl145s.mysql.com
# Root:	/data/bk/team_tree_merge/MERGE/mysql-4.1-opt/RESYNC

--- 1.460/sql/sql_select.cc	2006-10-19 14:35:01 +02:00
+++ 1.461/sql/sql_select.cc	2006-10-19 14:35:01 +02:00
@@ -933,17 +933,28 @@
 
     tmp_table_param.hidden_field_count= (all_fields.elements -
 					 fields_list.elements);
+    ORDER *tmp_group= ((!simple_group && !procedure &&
+                        !(test_flags & TEST_NO_KEY_GROUP)) ? group_list :
+                                                             (ORDER*) 0);
+    /*
+      Pushing LIMIT to the temporary table creation is not applicable
+      when there is ORDER BY or GROUP BY or there is no GROUP BY, but
+      there are aggregate functions, because in all these cases we need
+      all result rows.
+    */
+    ha_rows tmp_rows_limit= ((order == 0 || skip_sort_order ||
+                              test(select_options & OPTION_BUFFER_RESULT)) &&
+                             !tmp_group &&
+                             !thd->lex->current_select->with_sum_func) ?
+                            select_limit : HA_POS_ERROR;
+
     if (!(exec_tmp_table1 =
 	  create_tmp_table(thd, &tmp_table_param, all_fields,
-			   ((!simple_group && !procedure &&
-			     !(test_flags & TEST_NO_KEY_GROUP)) ?
-			    group_list : (ORDER*) 0),
+                           tmp_group,
 			   group_list ? 0 : select_distinct,
 			   group_list && simple_group,
 			   select_options,
-			   (order == 0 || skip_sort_order || 
-                            test(select_options & OPTION_BUFFER_RESULT)) ? 
-                             select_limit : HA_POS_ERROR,
+                           tmp_rows_limit,
 			   (char *) "")))
       DBUG_RETURN(1);
 
@@ -5567,6 +5578,13 @@
 			  thd->variables.max_heap_table_size) :
 		      thd->variables.tmp_table_size)/ table->reclength);
   set_if_bigger(table->max_rows,1);		// For dummy start options
+  /*
+    Push the LIMIT clause to the temporary table creation, so that we
+    materialize only up to 'rows_limit' records instead of all result records.
+  */
+  set_if_smaller(table->max_rows, rows_limit);
+  param->end_write_records= rows_limit;
+
   keyinfo=param->keyinfo;
 
   if (group)
@@ -5685,19 +5703,6 @@
 	 (ha_base_keytype) key_part_info->type == HA_KEYTYPE_VARTEXT) ?
 	0 : FIELDFLAG_BINARY;
     }
-  }
-
-  /*
-    Push the LIMIT clause to the temporary table creation, so that we
-    materialize only up to 'rows_limit' records instead of all result records.
-    This optimization is not applicable when there is GROUP BY or there is
-    no GROUP BY, but there are aggregate functions, because both must be
-    computed for all result rows.
-  */
-  if (!group && !thd->lex->current_select->with_sum_func)
-  {
-    set_if_smaller(table->max_rows, rows_limit);
-    param->end_write_records= rows_limit;
   }
 
   if (thd->is_fatal_error)				// If end of memory