An error occurred fetching the project authors.
  1. 17 Sep, 2011 1 commit
    • Sergey Petrunya's avatar
      BUG##849717: Crash in Item_func::fix_fields on second execution of a prepared... · 27cd8d7b
      Sergey Petrunya authored
      BUG##849717: Crash in Item_func::fix_fields on second execution of a prepared statement with semijoin
      - If convert_join_subqueries_to_semijoins() decides to wrap Item_in_subselect in Item_in_optimizer, 
        it should do so in prep_on_expr/prep_where, too, as long as they are present.
        There seems to be two possibilities of how we arrive in this function:
        - prep_on_expr/prep_where==NULL, and will be set later by simplify_joins()
        - prep_on_expr/prep_where!=NULL, and it is a copy_and_or_structure()-made copy of on_expr/where.
        the latter can happen for some (but not all!) nested joins. This bug was that we didn't handle this case.
      27cd8d7b
  2. 08 Sep, 2011 1 commit
    • Sergey Petrunya's avatar
      BUG#830993: Crash in end_read_record with derived table · 5673aa41
      Sergey Petrunya authored
      - Let join buffering code correctly take into account rowids needed 
        by DuplicateElimination when it is calculating minimum record sizes.
      - In JOIN_CACHE::write_record_data, added asserts that prevent us from 
        writing beyond the end of the buffer.
      5673aa41
  3. 05 Sep, 2011 2 commits
  4. 29 Aug, 2011 1 commit
    • Sergey Petrunya's avatar
      BUG#834534: Assertion `0' failed in replace_where_subcondition with semijoin subquery in HAVING · 945a595a
      Sergey Petrunya authored
      - The problem was that the code that made the check whether the subquery is an AND-part of the WHERE 
        clause didn't work correctly for nested subqueries. In particular, grand-child subquery in HAVING was 
        treated as if it was in the WHERE, which eventually caused an assert when replace_where_subcondition
        looked for the subquery predicate in the WHERE and couldn't find it there.
      
      - The fix: Removed implementation of "thd_marker approach". thd->thd_marker was used to determine the 
        location of subquery predicate: setup_conds() would set accordingly it when making the 
      
          {where|on_expr}->fix_fields(...)
      
        call so that AND-parts of the WHERE/ON clauses can determine they are the AND-parts. 
        Item_cond_or::fix_fields(), Item_func::fix_fields(), Item_subselect::fix_fields (this one was missed),
        and all other items-that-contain-items had to reset thd->thd_marker before calling fix_fields() for 
        their children items, so that the children can see they are not AND-parts of WHERE/ON.
      - The "thd_marker approach" required that a lot of code in different locations maintains correct value of
        thd->thd_marker, so it was replaced with:
      - The new approach with mark_as_condition_AND_part does not keep context in thd->thd_marker. Instead, 
        setup_conds() now calls
      
          {where|on_expr}->mark_as_condition_AND_part()
      
        and implementations of that function make sure that: 
         - parts of AND-expressions get the mark_as_condition_AND_part() call
         - Item_in_subselect objects record that they are AND-parts of WHERE/ON
      945a595a
  5. 16 Aug, 2011 1 commit
  6. 09 Aug, 2011 1 commit
  7. 21 Jul, 2011 1 commit
  8. 19 Jul, 2011 2 commits
  9. 15 Jul, 2011 2 commits
  10. 14 Jul, 2011 2 commits
  11. 13 Jul, 2011 2 commits
  12. 08 Jul, 2011 1 commit
    • Sergey Petrunya's avatar
      Set the default to be mrr=off,mrr_sort_keys=off: · 1492de85
      Sergey Petrunya authored
      - Set the default
      - Adjust the testcases so that 'new' tests are run with optimizations turned on.
      - Pull out relevant tests from "irrelevant" tests and run them with optimizations on.
      - Run range.test and innodb.test with both mrr=on and mrr=off
      1492de85
  13. 06 Jul, 2011 1 commit
  14. 05 Jul, 2011 1 commit
  15. 04 Jul, 2011 1 commit
    • Sergey Petrunya's avatar
      Change the default @@optimizer_switch setting from · c1de6f8b
      Sergey Petrunya authored
        semijoin=on,firstmatch=on,loosescan=on
      to
        semijoin=off,firstmatch=off,loosescan=off
      Adjust the testcases:
      - Modify subselect*.test and join_cache.test so that all tests
        use the same execution paths as before (i.e. optimizations that
        are being tested are enabled)
      - Let all other test files run with the new default settings (i.e.
        with new optimizations disabled)
      - Copy subquery testcases from these files into t/subselect_extra.test
        which will run them with new optimizations enabled.
      c1de6f8b
  16. 30 Jun, 2011 1 commit
    • Sergey Petrunya's avatar
      Fix buildbot failures: · e2eafc3b
      Sergey Petrunya authored
      - JOIN::prepare would have set JOIN::table_count to incorrect value (bad merge of MWL 106)
      - optimize_keyuse() would use table-bit as table number
        (the change in optimize_keyuse is also the reason for query plan changes. Not 
         expected to have much effect because only handles cases of no index statistics)
      - st_select_lex::register_dependency_item() ignored the fact that some of the 
        selects on the dependency paths could have been merged to their parents (because they 
        were mergeable VIEWs)
      - Undo the incorrect fix in Item_subselect::recalc_used_tables(): do not call 
        fix_after_pullout() for Item_subselect::Ref_to_outside members. 
      e2eafc3b
  17. 29 Jun, 2011 1 commit
  18. 28 Jun, 2011 2 commits
  19. 27 Jun, 2011 1 commit
  20. 22 Jun, 2011 3 commits
  21. 21 Jun, 2011 1 commit
  22. 15 Jun, 2011 2 commits
  23. 06 Jun, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #784441. · 059aff15
      Igor Babaev authored
      The code that added semi-join transformations missed checking
      the state of the fixed flag for the items built with the
      and_items function before calls of the fix_fields method.
      This could lead to an abort failure when the first argument
      of and_items() happened to be NULL.
       
      059aff15
  24. 02 Jun, 2011 1 commit
    • Sergey Petrunya's avatar
      BUG#787299: Valgrind complains on a join query with two IN subqueries · ebb130b1
      Sergey Petrunya authored
      - Don't attempt to construct FirstMatch access method if we've 
        just figured three lines above that it can't be used (because join
        prefix doesn't have the needed tables), and so have set 
          pos->first_firstmatch_table= MAX_TABLES 
        Attempts to analyze join->positions[MAX_TABLES] caused valgrind warnings
      ebb130b1
  25. 26 May, 2011 1 commit
  26. 20 May, 2011 1 commit
  27. 19 May, 2011 1 commit
    • Sergey Petrunya's avatar
      BUG#784723: Wrong result with semijoin + nested subqueries in maria-5.3 · d1138283
      Sergey Petrunya authored
      - in advance_sj_state(), remember join->cur_dups_producing_tables in 
        pos->prefix_dups_producing_tables *before* we modify it, so that 
        restore_prev_sj_state() restores cur_dups_producing_tables in all cases.
      - Updated test results in subselect_sj2[_jcl6].result (the original EXPLAIN
        was invalid there)
      d1138283
  28. 02 Apr, 2011 1 commit
    • Sergey Petrunya's avatar
      Make EXPLAIN better at displaying MRR/BKA: · 997445bc
      Sergey Petrunya authored
      - "Using MRR" is no longer shown with range access.
      - Instead, both range and BKA accesses will show one of the following:
        = "Rowid-ordered scan"
        = "Key-ordered scan"
        = "Key-ordered Rowid-ordered scan"
      depending on whether DS-MRR implementation will do scan keys in order, rowids in order,
      or both.
      - The patch also introduces a way for other storage engines/MRR implementations to
        pass information to EXPLAIN output about the properties of employed MRR scans.
      997445bc
  29. 18 Feb, 2011 1 commit
  30. 16 Feb, 2011 1 commit
  31. 03 Feb, 2011 1 commit
    • unknown's avatar
      MWL#89 · 648e6046
      unknown authored
      Adjusted test cases in accordance with the implementation.
      648e6046