1. 31 Mar, 2006 1 commit
    • unknown's avatar
      Fix for BUG#16710. · a01d48f9
      unknown authored
      The bug was due to a missed case in the detection of whether an index
      can be used for loose scan. More precisely, the range optimizer chose
      to use loose index scan for queries for which the condition(s) over
      an index key part could not be pushed to the index together with the
      loose scan.
      
      As a result, loose index scan was selecting the first row in the
      index with a given GROUP BY prefix, and was applying the WHERE
      clause after that, while it should have inspected all rows with
      the given prefix, and apply the WHERE clause to all of them.
      
      The fix detects and skips such cases.
      
      
      mysql-test/r/group_min_max.result:
        Added test for BUG#16710.
      mysql-test/t/group_min_max.test:
        Added test for BUG#16710.
      sql/item.cc:
        Added new method [Item | Item_field]::find_item_in_field_list_processor.
      sql/item.h:
        Added new method [Item | Item_field]::find_item_in_field_list_processor.
      sql/opt_range.cc:
        Handle the case when there is no MIN/MAX aggregate function, and a
        keypart of the index being considered, that is after the GROUP BY
        prefix, is used in the WHERE clause and the condition where it is
        used cannot be pushed to the index.
        If this is the case, we rule out this index.
      a01d48f9
  2. 16 Feb, 2006 1 commit
    • unknown's avatar
      Merge mysql.com:/home/stewart/Documents/MySQL/5.0/main · 82f64553
      unknown authored
      into  mysql.com:/home/stewart/Documents/MySQL/5.0/bug17411-thisisaverylongnamethatshouldbewaylongerthanthe128limitthatweprivouslyhadbutireallywantotestitandseethatitdoesreallywork.nowitshouldbeabout160charslongnonow.iwonderifanythingwillchokeornotwiththisoutrageouslylongpathname
      
      
      82f64553
  3. 15 Feb, 2006 10 commits
  4. 14 Feb, 2006 16 commits
  5. 13 Feb, 2006 12 commits