1. 27 Jan, 2012 1 commit
    • Sergey Petrunya's avatar
      BUG#922254: Assertion `0' failed at item_cmpfunc.cc:5899: Item*... · 53fde5bb
      Sergey Petrunya authored
      BUG#922254: Assertion `0' failed at item_cmpfunc.cc:5899: Item* Item_equal::get_first(JOIN_TAB*, Item*)
      Fixed Item* Item_equal::get_first(JOIN_TAB *context, Item *field_item) to work correctly in the case where:
      - context!= NO_PARTICULAR_TAB, it points to a table within SJ-Materialization nest
      - field_item points to an item_equal that has a constant Item_field but does not have any fields
        from tables that are within semi-join nests.
      
      
      
      53fde5bb
  2. 26 Jan, 2012 2 commits
  3. 25 Jan, 2012 4 commits
  4. 23 Jan, 2012 2 commits
  5. 22 Jan, 2012 2 commits
  6. 19 Jan, 2012 3 commits
    • Sergey Petrunya's avatar
      BUG#912513: Wrong result (missing rows) with join_cache_hashed+materialization+semijoin=on · 9f60aa27
      Sergey Petrunya authored
      - equality substitution code was geared towards processing WHERE/ON clauses.
        that is, it assumed that it was doing substitions on the code that 
         = wasn't attached to any particular join_tab yet
         = was going to be fed to make_join_select() which would take the condition
           apart and attach various parts of it to tables inside/outside semi-joins.
      - However, somebody added equality substition for ref access. That is, if 
        we have a ref access on TBL.key=expr, they would do equality substition in
        'expr'. This possibility wasn't accounted for.
      - Fixed equality substition code by adding a mode that does equality 
        substition under assumption that the processed expression will be 
        attached to a certain particular table TBL.
      9f60aa27
    • Sergey Petrunya's avatar
      BUG#912538: Wrong result (missing rows) with semijoin=on, firstmatch=on, ... · 8bedf1ea
      Sergey Petrunya authored
      - setup_semijoin_dups_elimination() would incorrectly set join_tab->do_firstmatch 
        when the join order had outer tables interleaved with inner.
      8bedf1ea
    • Vladislav Vaintroub's avatar
      Fix compiler warning on Windows. · 0e975ded
      Vladislav Vaintroub authored
      0e975ded
  7. 18 Jan, 2012 6 commits
  8. 17 Jan, 2012 1 commit
  9. 13 Jan, 2012 1 commit
  10. 11 Jan, 2012 1 commit
  11. 10 Jan, 2012 2 commits
  12. 09 Jan, 2012 1 commit
  13. 08 Jan, 2012 2 commits
  14. 03 Jan, 2012 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #910083. · cd55894a
      Igor Babaev authored
      The patch for bug 685411 erroneously removed a call of engine->set_thd()
      from Item_subselect::fix_fields().
      cd55894a
  15. 30 Dec, 2011 3 commits
  16. 29 Dec, 2011 1 commit
  17. 28 Dec, 2011 1 commit
  18. 27 Dec, 2011 1 commit
  19. 26 Dec, 2011 1 commit
  20. 24 Dec, 2011 1 commit
    • Igor Babaev's avatar
      Back-ported the patch of the mysql-5.6 code line that · 2b1f0b87
      Igor Babaev authored
      fixed several defects in the greedy optimization:
      
      1) The greedy optimizer calculated the 'compare-cost' (CPU-cost)
         for iterating over the partial plan result at each level in
         the query plan as 'record_count / (double) TIME_FOR_COMPARE'
      
         This cost was only used locally for 'best' calculation at each
         level, and *not* accumulated into the total cost for the query plan.
      
         This fix added the 'CPU-cost' of processing 'current_record_count'
         records at each level to 'current_read_time' *before* it is used as
         'accumulated cost' argument to recursive 
         best_extension_by_limited_search() calls. This ensured that the
         cost of a huge join-fanout early in the QEP was correctly
         reflected in the cost of the final QEP.
      
         To get identical cost for a 'best' optimized query and a
         straight_join with the same join order, the same change was also
         applied to optimize_straight_join() and get_partial_join_cost()
      
      2) Furthermore to get equal cost for 'best' optimized query and a
         straight_join the new code substrcated the same '0.001' in
         optimize_straight_join() as it had been already done in
         best_extension_by_limited_search()
      
      3) When best_extension_by_limited_search() aggregated the 'best' plan a
         plan was 'best' by the check :
      
         'if ((search_depth == 1) || (current_read_time < join->best_read))'
      
         The term '(search_depth == 1' incorrectly caused a new best plan to be
         collected whenever the specified 'search_depth' was reached - even if
         this partial query plan was more expensive than what we had already
         found.
      2b1f0b87
  21. 20 Dec, 2011 2 commits
  22. 19 Dec, 2011 1 commit
    • unknown's avatar
      Backport of WL#5953 from MySQL 5.6 · 072073c0
      unknown authored
      The patch differs from the original MySQL patch as follows:
      - All test case differences have been reviewed one by one, and
        care has been taken to restore the original plan so that each
        test case executes the code path it was designed for.
      - A bug was found and fixed in MariaDB 5.3 in
        Item_allany_subselect::cleanup().
      - ORDER BY is not removed because we are unsure of all effects,
        and it would prevent enabling ORDER BY ... LIMIT subqueries.
      - ref_pointer_array.m_size is not adjusted because we don't do
        array bounds checking, and because it looks risky.
      
      Original comment by Jorgen Loland:
      -------------------------------------------------------------
      WL#5953 - Optimize away useless subquery clauses
            
      For IN/ALL/ANY/SOME/EXISTS subqueries, the following clauses are 
      meaningless:
            
      * ORDER BY (since we don't support LIMIT in these subqueries)
      * DISTINCT
      * GROUP BY if there is no HAVING clause and no aggregate 
        functions
            
      This WL detects and optimizes away these useless parts of the
      query during JOIN::prepare()
      072073c0