1. 09 Nov, 2010 3 commits
  2. 08 Nov, 2010 2 commits
  3. 03 Nov, 2010 1 commit
  4. 02 Nov, 2010 3 commits
  5. 01 Nov, 2010 5 commits
  6. 31 Oct, 2010 2 commits
  7. 30 Oct, 2010 3 commits
    • Igor Babaev's avatar
      Fixed LP bug #668290. · df323421
      Igor Babaev authored
      Prohibited to use hash join algorithm BNLH if join attributes
      need non-binary collations. It has to be done because BNLH does
      not support join for such attributes yet.
      Later this limitations will be lifted.
      
      Changed default collations for the schemes of some test cases
      to preserve the old execution plans.
      df323421
    • Igor Babaev's avatar
      Merge. · 0b72fd88
      Igor Babaev authored
      0b72fd88
    • Igor Babaev's avatar
      Fixed bug #665049. · d48a8b60
      Igor Babaev authored
      The bug could cause wrong results for queries over Maria tables when
      index condition pushdown was used.
      d48a8b60
  8. 29 Oct, 2010 2 commits
  9. 28 Oct, 2010 3 commits
  10. 27 Oct, 2010 6 commits
  11. 26 Oct, 2010 3 commits
    • unknown's avatar
      Fixed LP bug #601156 · b4d5f30a
      unknown authored
      The cause for this bug is that MariaDB 5.3 still processes derived tables
      (subqueries in the FROM clause) by fully executing them during the parse
      phase. This will be remedied by MWL#106 once merged into the main 5.3.
      
      The assert statement is triggered when MATERIALIZATION is ON for EXPLAIN
      EXTENDED for derived tables with an IN subquery as follows:
      - mysql_parse calls JOIN::exec for the derived table as if it is regular
        execution (not explain).
      - When materialization is ON, this call goes all the way to
        subselect_hash_sj_engine::exec, which creates a partial match engine
        because of NULL presence.
      - In order to proceed with normal execution, the hash_sj engine substitutes
        itself with the created partial match engine.
      - After the parse phase it turns out that this execution was part of
        EXPLAIN EXTENDED, which in turn calls
        Item_cond::print -> ... -> Item_subselect::print,
        which calls engine->print().
        Since subselect_hash_sj_engine::exec substituted the current
        Item_subselect engine with a  partial match engine, eventually we call
        its ::print() method. However the partial match engines are designed only
        for execution, hence there is no implementation of this print() method.
      
      The fix temporarily removes the assert, until this code is merged with
      MWL#106.
      b4d5f30a
    • Sergey Petrunya's avatar
    • Sergei Golubchik's avatar
      fixes for windows · 7c24e8d5
      Sergei Golubchik authored
      7c24e8d5
  12. 25 Oct, 2010 3 commits
    • unknown's avatar
      Fixed LP bug #609121 · db4738a1
      unknown authored
      The bug was a result of missing logic to handle the case
      when there are 'expensive' predicates that are not evaluated
      during constant table optimization. Such is the case for
      the IN predicate, which is considered expensive if it is
      computed via materialization. In general this bug can be
      triggered with any expensive predicate instead of IN.
      
      When FALSE constant predicates are not evaluated during constant
      optimization, the execution path changes so that instead of
      setting JOIN::zero_result_cause after make_join_select, and
      exiting JOIN::exec via the call to return_zero_rows(), execution
      ends in JOIN::exec in the branch:
      if (join->tables == join->const_tables)
      {
        ...
        else if (join->send_row_on_empty_set())
           ...
           rc= join->result->send_data(*columns_list);
      }
      Unlike return_zero_rows(), this branch didn't evaluate the
      having clause of the query.
      
      The patch adds a call to evaluate the HAVING clause of a query even
      when all tables are constant, because even for an empty result set
      some aggregate functions may produce a NULL value.
      db4738a1
    • Sergei Golubchik's avatar
      merge with 5.1 · 04a4b433
      Sergei Golubchik authored
      04a4b433
    • Sergei Golubchik's avatar
      forgotten option handled · 37a78d68
      Sergei Golubchik authored
      37a78d68
  13. 24 Oct, 2010 2 commits
    • Igor Babaev's avatar
      Fixed LP bug #664508. · 0c53cd1e
      Igor Babaev authored
      When join buffers are employed no index scan for the first
      table with grouping columns can be used.
      
      
      
      mysql-test/r/join_cache.result:
        Added a test case for bug #664508.
        Sorted results for some other test cases.
      mysql-test/t/join_cache.test:
        Added a test case for bug #664508.
        Sorted results for some other test cases.
      0c53cd1e
    • Sergei Golubchik's avatar
      bugfix: engine defined table options were not showing up in... · 62d31f67
      Sergei Golubchik authored
      bugfix: engine defined table options were not showing up in INFORMATION_SCHEMA.TABLES.CREATE_OPTIONS
      62d31f67
  14. 22 Oct, 2010 2 commits
    • Igor Babaev's avatar
      Fixed LP bug #663818. · de69dbae
      Igor Babaev authored
      After the patch for bug 663840 had been applied the test case for
      bug 663818 triggered the assert introduced by this patch.
      It happened because the the patch turned out to be incomplete:
      the space needed for a key entry must be taken into account
      for the record written into the buffer, and, for the next record
      as well, when figuring out whether the record being written is
      the last for the buffer or not. 
      de69dbae
    • Igor Babaev's avatar
      Fixed LP bug #663840. · ca862231
      Igor Babaev authored
      When adding a new record into the join buffer that is employed by
      BNLH join algorithm the writing procedure JOIN_CACHE::write_record_data 
      checks whether there is enough space for the record in the buffer.
      When doing this it must take into account a possible new key entry
      added to the buffer. It might happen, as it has been demonstrated by
      the bug test case, that there is enough remaining space in the buffer
      for the record, but not for the additional key entry for this record.
      In this case the key entry overwrites the end of the record that might
      cause a crash or wrong results.
      Fixed by taking into account a possible addition of new key entry when
      estimating the remaining free space in the buffer.
      ca862231