1. 19 Jun, 2006 1 commit
    • gkodinov@mysql.com's avatar
      * Bug #9676: INSERT INTO x SELECT .. FROM x LIMIT 1; slows down with big · c5ed7a87
      gkodinov@mysql.com authored
                    tables
      Currently in INSERT ... SELECT ... LIMIT ... the compiler uses a 
      temporary table to store the results of SELECT ... LIMIT .. and then
      uses that table as a source for INSERT. The problem is that in some cases
      it actually skips the LIMIT clause in doing that and materializes the 
      whole SELECT result set regardless of the LIMIT.
      This fix is limiting the process of filling up the temp table with only 
      that much rows that will be actually used by propagating the LIMIT value.
      c5ed7a87
  2. 13 Jun, 2006 2 commits
    • evgen@moonbone.local's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-4.1-opt · d4942a26
      evgen@moonbone.local authored
      into moonbone.local:/work/16377-bug-4.1-opt-mysql
      d4942a26
    • evgen@moonbone.local's avatar
      Fixed bug#16377: result of DATE/TIME functions were compared as strings which · 67de8c46
      evgen@moonbone.local authored
      can lead to a wrong result.
      
      All date/time functions has the STRING result type thus their results are
      compared as strings. The string date representation allows a user to skip 
      some of leading zeros. This can lead to wrong comparison result if a date/time 
      function result is compared to such a string constant.
      
      The idea behind this bug fix is to compare results of date/time functions
      and data/time constants as ints, because that date/time representation is 
      more exact. To achieve this the agg_cmp_type() is changed to take in the
      account that a date/time field or an date/time item should be compared 
      as ints.
      
      This bug fix is partially back ported from 5.0.
      
      The agg_cmp_type() function now accepts THD as one of parameters. 
      In addition, it now checks if a date/time field/function is present in the
      list. If so, it tries to coerce all constants to INT to make date/time
      comparison return correct result. The field for the constant coercion is
      taken from the Item_field or constructed from the Item_func. In latter case
      the constructed field will be freed after conversion of all constant items.
      Otherwise the result is same as before - aggregated with help of the
      item_cmp_type() function.
      
      From the Item_func_between::fix_length_and_dec() function removed the part
      which was converting date/time constants to int if possible. Now this is 
      done by the agg_cmp_type() function.
      
      The new function result_as_longlong() is added to the Item class. 
      It indicates that the item is a date/time item and result of it can be
      compared as int. Such items are date/time fields/functions.
      
      Correct val_int() methods are implemented for classes Item_date_typecast, 
      Item_func_makedate, Item_time_typecast, Item_datetime_typecast. All these
      classes are derived from Item_str_func and Item_str_func::val_int() converts
      its string value to int without regard to the date/time type of these items.
      
      Arg_comparator::set_compare_func() and Arg_comparator::set_cmp_func()
      functions are changed to substitute result type of an item with the INT_RESULT
      if the item is a date/time item and another item is a constant. This is done
      to get a correct result of comparisons like date_time_function() = string_constant.
      67de8c46
  3. 03 Jun, 2006 1 commit
  4. 02 Jun, 2006 3 commits
    • igor@rurik.mysql.com's avatar
      Merge ibabaev@bk-internal.mysql.com:/home/bk/mysql-4.1-opt · d02f254e
      igor@rurik.mysql.com authored
      into  rurik.mysql.com:/home/igor/mysql-4.1-opt
      d02f254e
    • igor@rurik.mysql.com's avatar
      Fixed bug #18206. · 37e049db
      igor@rurik.mysql.com authored
      The bug report revealed two problems related to min/max optimization:
      1. If the length of a constant key used in a SARGable condition for
      for the MIN/MAX fields is greater than the length of the field an 
      unwanted warning on key truncation is issued;
      2. If MIN/MAX optimization is applied to a partial index, like INDEX(b(4))
      than can lead to returning a wrong result set.
      37e049db
    • gkodinov@mysql.com's avatar
      Bug #4981: 4.x and 5.x produce non-optimal execution path, · b519877c
      gkodinov@mysql.com authored
              3.23 regression test failure
      
      The member SEL_ARG::min_flag was not initialized, 
      due to which the condition for no GEOM_FLAG in function 
      key_or did not choose "Range checked for each record" as 
      the correct access method.
      b519877c
  5. 30 May, 2006 1 commit
  6. 29 May, 2006 1 commit
    • evgen@moonbone.local's avatar
      Fixed bug#18360: Incorrect type coercion in IN() results in false comparison · 641f852d
      evgen@moonbone.local authored
      The IN() function uses agg_cmp_type() to aggregate all types of its arguments
      to find out some common type for comparisons. In this particular case the 
      char() and the int was aggregated to double because char() can contain values
      like '1.5'. But all strings which do not start from a digit are converted to
      0. thus 'a' and 'z' become equal. 
      This behaviour is reasonable when all function arguments are constants. But 
      when there is a field or an expression this can lead to false comparisons. In
      this case it makes more sense to coerce constants to the type of the field
      argument.
      
      The agg_cmp_type() function now aggregates types of constant and non-constant
      items separately. If some non-constant items will be found then their
      aggregated type will be returned. Thus after the aggregation constants will be
      coerced to the aggregated type. 
      641f852d
  7. 28 May, 2006 1 commit
    • evgen@moonbone.local's avatar
      Fixed bug#19225: unchecked error results in server crash · 1f30bf5a
      evgen@moonbone.local authored
      In multi-table delete a table for delete can't be used for selecting in
      subselects. Appropriate error was raised but wasn't checked which leads to a
      crash at the execution phase.
      
      The mysql_execute_command() now checks for errors before executing select
      for multi-delete.
      1f30bf5a
  8. 23 May, 2006 3 commits
  9. 22 May, 2006 1 commit
  10. 21 May, 2006 1 commit
  11. 20 May, 2006 2 commits
  12. 19 May, 2006 4 commits
  13. 17 May, 2006 2 commits
  14. 16 May, 2006 9 commits
  15. 15 May, 2006 5 commits
  16. 14 May, 2006 3 commits