1. 16 Oct, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #22342: No results returned for query using max and group by · 0e954d2c
      gkodinov/kgeorge@macbook.gmz authored
       When using index for group by and range access the server isolates    
       a set of ranges based on the conditions over the key parts of the
       index used. Then it uses only the ranges over the GROUP BY fields to
       jump from one group to another. Since the GROUP BY fields may form a
       prefix over the index, we may use only a prefix of the ranges produced
       by the range optimizer.
       Each range contains a notion on whether it includes its border values.
       The problem is that when using a range prefix, the last range is open
       because it assumes that there is a range on the next keypart. Thus when
       we use a prefix range as it is, it excludes all border values.
       The solution is when ignoring the suffix of the range conditions 
       (to jump over the GROUP BY prefix only) the server must change the 
       remaining intervals so they always contain their borders, e.g. 
       if the whole range was :
       (1,-inf) <= (<group_by_col>,<min_max_arg_col>) < (1, 3) we must make
       (1) <= (<group_by_col>) <= (1) because (a,b) < (c1,c2) means :
       a < c1 OR (a = c1 AND b < c2).
      0e954d2c
  2. 20 Sep, 2006 6 commits
  3. 19 Sep, 2006 4 commits
  4. 18 Sep, 2006 5 commits
  5. 16 Sep, 2006 2 commits
    • igor@rurik.mysql.com's avatar
      Fixed bug #22085: Crash on the execution of a prepared · dd3b8e4f
      igor@rurik.mysql.com authored
      statement that uses an aggregating IN subquery with 
      HAVING clause.
      A wrong order of the call of split_sum_func2 for the HAVING
      clause of the subquery and the transformation for the 
      subquery resulted in the creation of a andor structure
      that could not be restored at an execution of the prepared
      statement.
      dd3b8e4f
    • igor@rurik.mysql.com's avatar
      Fixed bug #21493: crash for the second execution of a function · d3d3cef8
      igor@rurik.mysql.com authored
      containing a select statement that uses an aggregating IN subquery.
      Added a parameter to the function fix_prepare_information 
      to restore correctly the having clause for the second execution.
      Saved andor structure of the having conditions at the proper moment
      before any calls of split_sum_func2 that could modify the having structure
      adding new Item_ref objects. (These additions, are produced not with 
      the statement mem_root, but rather with the execution mem_root.)
      d3d3cef8
  6. 15 Sep, 2006 22 commits