1. 24 Oct, 2006 1 commit
  2. 21 Oct, 2006 1 commit
  3. 20 Oct, 2006 7 commits
  4. 19 Oct, 2006 12 commits
  5. 18 Oct, 2006 2 commits
  6. 17 Oct, 2006 10 commits
  7. 16 Oct, 2006 7 commits
    • igor@rurik.mysql.com's avatar
      Fixed bug #19579: at range analysis optimizer did not take into · c467be8d
      igor@rurik.mysql.com authored
      account predicates that become sargable after reading const tables.
      In some cases this resulted in choosing non-optimal execution plans.
      Now info of such potentially saragable predicates is saved in
      an array and after reading const tables we check whether this
      predicates has become saragable.
      c467be8d
    • gkodinov/kgeorge@rakia.(none)'s avatar
      Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · a5899ea8
      gkodinov/kgeorge@rakia.(none) authored
      into  rakia.(none):/home/kgeorge/mysql/autopush/B22342-5.0-opt
      a5899ea8
    • 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
    • istruewing@chilla.local's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0-engines · b14e9a7a
      istruewing@chilla.local authored
      into  chilla.local:/home/mydev/mysql-5.0-bug12240
      b14e9a7a
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #22367: Optimizer uses ref join type instead of eq_ref for simple join on · a1310d84
      gkodinov/kgeorge@macbook.gmz authored
                   strings
      MySQL is setting the flag HA_END_SPACE_KEYS for all the keys that reference
      text or varchar columns with collation different than binary.
      This was done to handle correctly the situation where a lookup on such a key
      may return more than 1 row because of the presence of many rows that differ
      only by the amount of trailing space in the table's string column.
      Inserting such values however appears to violate the unique checks on 
      INSERT/UPDATE. Thus that flag must not be set as it will prevent the optimizer
      from choosing a faster access method.
      This fix removes the setting of the HA_END_SPACE_KEYS flag.
      a1310d84
    • gkodinov/kgeorge@macbook.gmz's avatar
      Merge bk-internal:/home/bk/mysql-5.0-opt · abad78f4
      gkodinov/kgeorge@macbook.gmz authored
      into  macbook.gmz:/Users/kgeorge/mysql/work/B14019-5.0-opt
      abad78f4
    • gkodinov/kgeorge@macbook.gmz's avatar