An error occurred fetching the project authors.
  1. 22 Feb, 2011 1 commit
    • unknown's avatar
      MWL#89 · 759d71eb
      unknown authored
      Split the tests for MWL#89 into two parts - one for bugs
      (currently active), and one for functionality tets
      (currently in progress, and thus disabled).
      
      Disable the test for LP BUG#718593.
      759d71eb
  2. 15 Feb, 2011 1 commit
    • unknown's avatar
      Fix for LP BUG#714808 and LP BUG#719280. · 96efe1ca
      unknown authored
      The patch also adjusts several instable test results
      to order the result.
      
      Analysis:
      
      The function prev_record_reads() may skip (jump over)
      some query plan nodes where record_count < 1. At the
      same time, even though get_partial_join_cost() uses
      all first N plan nodes after the last constant table,
      it may produce a smaller record_count than
      prev_record_reads(), because the record count for
      some plan nodes may be < 1, and these nodes may not
      participate in prev_record_reads.
      
      Solution:
      The current solution is to treat the result of
      get_partial_join_cost() as the upper bound for the
      total number of unique lookup keys.
      96efe1ca
  3. 14 Feb, 2011 1 commit
    • unknown's avatar
      Fix LP BUG#718578 · 6c45d903
      unknown authored
      This bug extends the fix for LP BUG#715027 to cover one
      more case of an Item being transformed, and its property
      Item::with_subselect not being updated because
      quick_fix_fields doesn't recalculate any properties.
      6c45d903
  4. 13 Feb, 2011 1 commit
    • unknown's avatar
      Fix LP BUG#715027 · 2aeb4170
      unknown authored
      Analysis:
      Before calling:
        write_record= (select->skip_record(thd) > 0);
      the function find_all_keys needs to restore the original read/write
      sets of the table that is sorted if the condition select->cond
      contains a subquery.
      
      This didn't happen in this test case because the flag "with_subselect"
      was not set properly for select->cond.
      
      The reason for the flag not being set properly, was that this condition
      was rewritten by add_cond_and_fix() inside make_join_select() by:
      
            /* Add conditions added by add_not_null_conds(). */
            if (tab->select_cond)
              add_cond_and_fix(thd, &tmp, tab->select_cond);
      
      However, the function add_cond_and_fix() called the shortcut method
      Item::quick_fix_field() that didn't update the "with_subselect"
      property.
      
      Solution:
      Call the complete Item::fix_fields() to update all Item properties,
      including "with_subselect".
      2aeb4170
  5. 11 Feb, 2011 1 commit
    • unknown's avatar
      Fix LP BUG#715034 · cd349466
      unknown authored
      Analysis:
      The failed assert is a result of calling Item_sum_distinct::clear()
      on an incomplete object for which Item_sum_distinct::setup() was
      not yet called.
      
      The reason is that JOIN::exec for the outer query calls JOIN::reinit()
      for all its subqueries, which in turn calls clear() for all aggregate
      functions of the subqueries. The call stack is:
      mysql_explain_union -> mysql_select -> JOIN::exec -> select_desribe ->
      mysql_explain_union -> mysql_select -> JOIN::reinit
      
      This assert doesn't fail in the main 5.3 because constant subqueries
      are being executed during the optimize phase of the outer query,
      thus the Unique object is created before calling JOIN::exec for the
      outer query, and Item_sum_distinct::clear() actually cleans the
      Unique object.
      
      Solution:
      The best solution is the obvious one - substitute the assert with
      a test whether Item_sum_distinct::tree is NULL.
      cd349466
  6. 10 Feb, 2011 2 commits
    • unknown's avatar
      Fix LP BUG#714999 · ac6653aa
      unknown authored
      Analysis:
      The crash in EXPLAIN resulted from an attempt to print the
      name of the internal temporary table created to compute
      distinct for the innermost subquery of the test case.
      Such tables do not have a corresponding TABLE_LIST (table
      reference), hence the crash. The reason for this was that
      the subquery was executed as part of constant condition
      evaluation before EXPLAIN attempts to print the table name.
      During the subquery execution, the subquery JOIN_TAB and
      its table are substituted by a temporary table in
      make_simple_join.
      
      Solution:
      Similar to the analogous case for other Items than the
      IS NULL function, do not evaluate expensive constant
      conditions.
      ac6653aa
    • unknown's avatar
      MWL#89 · 6a66bf31
      unknown authored
      Fixed LP BUG#714808 Assertion `outer_lookup_keys <= outer_record_count'
      
      Analysis:
      
      The function best_access_path() computes the number or records as
      follows:
      
      ...
            if (rec < MATCHING_ROWS_IN_OTHER_TABLE)
              rec= MATCHING_ROWS_IN_OTHER_TABLE; // Fix for small tables
      ...
                    if (table->quick_keys.is_set(key))
                      records= (double) table->quick_rows[key];
                    else
                    {
                      /* quick_range couldn't use key! */
                      records= (double) s->records/rec;
                    }
      
      Above MATCHING_ROWS_IN_OTHER_TABLE == 10, and s->records == 1,
      thus we get an estimated 0.1 records. As a result JOIN::get_partial_join_cost()
      for the outer query computes outer_record_count == 0.1 records, which is
      meaningless in this context.
      
      Solution:
      Round row count estimates that are < 1 to 1.
      6a66bf31
  7. 05 Nov, 2010 1 commit
  8. 02 Nov, 2010 1 commit
    • unknown's avatar
      Fixed LP BUG#652727 and LP BUG#643424. · 9f2bddbd
      unknown authored
      The fixes for #643424 was part of the fix for #652727, that's why both
      fixes are pushed together.
      
      - The cause for #643424 was the improper use of get_partial_join_cost(),
        which assumed that the 'n_tables' parameter was the upper bound for
        query plan node indexes.
        Fixed by generalizing get_partial_join_cost() as a method that computes
        the cost of any partial join.
      
      - The cause of #652727 was that JOIN::choose_subquery_plan() incorrectly
        deleted the contents of the old keyuse array in the cases when an injected
        plan would not provide more key accesses, and reoptimization was not actually
        performed.
      9f2bddbd
  9. 23 Oct, 2010 1 commit
  10. 20 Oct, 2010 1 commit
    • unknown's avatar
      MWL#89: Cost-based choice between Materialization and IN->EXISTS transformation · e85a4cb6
      unknown authored
      - Added more tests to the MWL#89 specific test, and made the test more modular.
      - Updated test files.
      - Fixed a memory leak.
      - More comments.
      
      mysql-test/r/subselect_mat.result:
        - Updated the test file to reflect the new optimizer switches related to
          materialized subquery execution.
        - Added one extra test to test all cases that expose BUG#40037 (this is an old bug from 5.x).
        - Updated the test result with correct results that expose BUG#40037.
      mysql-test/t/subselect_mat.test:
        - Updated the test file to reflect the new optimizer switches related to
          materialized subquery execution.
        - Added one extra test to test all cases that expose BUG#40037 (this is an old bug from 5.x).
        - Updated the test result with correct results that expose BUG#40037.
      sql/sql_select.cc:
        Fixed a memory leak reported by Valgrind.
      e85a4cb6
  11. 09 Oct, 2010 1 commit