An error occurred fetching the project authors.
  1. 25 Oct, 2011 1 commit
    • Sergey Petrunya's avatar
      BUG#877288: Wrong result with semijoin + materialization + multipart key · 8e6440df
      Sergey Petrunya authored
      - when create_ref_for_key() is constructing a ref access for
        a table that's inside a SJ-Materialization nest, it may not 
        use references to fields of tables that are unside the nest (because 
        these fields will not yet have values when ref access will be used)
        
        The check was performed in the first of create_ref_for_key's loops (the 
        one which counts how many key parts are usable) but not in the second
        (the one which actually fills the TABLE_REF structure). 
      8e6440df
  2. 24 Oct, 2011 1 commit
  3. 20 Oct, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #878199. · e7a7e2a0
      Igor Babaev authored
      The function JOIN::drop_unused_derived_keys could erroneously set
      the value of REF::key to 0 for a joined materialized view/derived table
      in the case when no REF access to the table was used by the query
      execution plan. This could cause a crash of the server.
      e7a7e2a0
  4. 16 Oct, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #874006. · f5955f87
      Igor Babaev authored
      This bug manifested itself with queries containing non-correlated
      IN subqueries over materialized views/derived tables.  
      The bug happened because the code of the function generate_derived_keys did
      not take into account that the function could be called twice when the
      optimizer was deciding whether in-exist transformation should be applied.
      f5955f87
  5. 12 Oct, 2011 3 commits
  6. 11 Oct, 2011 2 commits
    • Sergey Petrunya's avatar
      BUG#869012: Wrong result with semijoin + materialization + AND in WHERE · 039da95e
      Sergey Petrunya authored
      - in make_join_select(), use the correct condition to check whether the current table is a SJM nest (the previous 
        condition used to be correct before, but then sj-materialization temp table creation was moved to happen before
        make_join_select was called)
      039da95e
    • Igor Babaev's avatar
      Fixed LP bug #870046. · 8feff690
      Igor Babaev authored
      This bug is a consequence of the fix in the function add_ref_to_table_cond
      for LP bug 826935 that turned out to be not quite correct: it tried to AND
      the same generated condition with two different other conditions.
      This patch creates a copy of the generated condition if the condition needs
      to be ANDed with two different items.
      8feff690
  7. 04 Oct, 2011 1 commit
  8. 01 Oct, 2011 2 commits
  9. 30 Sep, 2011 1 commit
    • Sergey Petrunya's avatar
      BUG#860553: Crash in create_ref_for_key with semijoin + materialization · f5987a0c
      Sergey Petrunya authored
      - The problem was that JOIN::save/restore_query_plan() did not save/restore parts of 
        the query plan that are located inside SJ_MATERIALIZATION_INFO structures. This could
        cause parts of one plan to be used with another, which led get_best_combination() to
        constructing non-sensical join plans (and crash).
        Fixed by saving/restoring SJM parts of the query plans.
      
      - check_and_do_in_subquery_rewrites() will not set SUBS_MATERIALIZATION flag when it 
        records that the subquery predicate is to be converted into semi-join. 
        If convert_join_subqueries_to_semijoins() later decides not to convert to semi-join,
        let it set SUBS_MATERIALIZATION flag, if appropriate.
      f5987a0c
  10. 29 Sep, 2011 1 commit
  11. 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
  12. 06 Sep, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #838633. · da59130e
      Igor Babaev authored
      For any query JOIN::optimize() should call the method
      SELECT::save_leaf_tables after the last transformation
      that utilizes the statement memory rather than the 
      execution memory.
        
      da59130e
  13. 05 Sep, 2011 1 commit
  14. 03 Sep, 2011 1 commit
    • Michael Widenius's avatar
      Fixed lp:828514 "Assertion `! is_set()' failed in... · 949984be
      Michael Widenius authored
      Fixed lp:828514 "Assertion `! is_set()' failed in Diagnostics_area::set_ok_status with derived table + subquery + concurrent DML"
      
      
      sql/item_subselect.cc:
        Added check of error condtions (safety)
      sql/sql_join_cache.cc:
        Added DBUG to some functions.
        Added error checking for calls to check_match(); This fixed the bug.
      sql/sql_select.cc:
        Moved variable assignment to be close to where it's used (cleanup)
      949984be
  15. 02 Sep, 2011 1 commit
  16. 01 Sep, 2011 1 commit
    • unknown's avatar
      Fix for bug lp:834492 · ea8aa329
      unknown authored
      Analysis:
      In the test query semi-join merges the inner-most subquery
      into the outer subquery, and the optimization of the merged
      subquery finds some new index access methods. Later the
      IN-EXISTS transformation is applied to the unmerged subquery.
      Since the optimizer is instructed to not consider
      materialization, it reoptimizes the plan in-place to take into
      account the new IN-EXISTS conditions. Just before reoptimization
      JOIN::choose_subquery_plan resets the query plan, which also
      resets the access methods found during the semi-join merge.
      Then reoptimization discovers there are no new access methods,
      but it leaves the query plan in its reset state. Later semi-join
      crashes because it assumes these access methods are present.
      
      Solution:
      When reoptimizing in-place, reset the query plan only after new
      access methods were discovered. If no new access methods were
      discovered, leave the current plan as it was.
      ea8aa329
  17. 29 Aug, 2011 1 commit
  18. 26 Aug, 2011 1 commit
    • unknown's avatar
      Fix bug lp:827416 · 2df19147
      unknown authored
      Analysis:
      Constant table optimization of the outer query finds that
      the right side of the equality is a constant that can
      be used for an eq_ref access to fetch one row from t1,
      and substitute t1 with a constant. Thus constant optimization
      triggers evaluation of the subquery during the optimize
      phase of the outer query.
      
      The innermost subquery requires a plan with a temporary
      table because with InnoDB tables the exact count of rows
      is not known, and the empty tables cannot be optimzied
      way. JOIN::exec for the innermost subquery substitutes
      the subquery tables with a temporary table.
      
      When EXPLAIN gets to print the tables in the innermost
      subquery, EXPLAIN needs to print the name of each table
      through the corresponding TABLE_LIST object. However,
      the temporary table created during execution doesn't
      have a corresponding TABLE_LIST, so we get a null
      pointer exception.
      
      Solution:
      The solution is to forbid using expensive constant
      expressions for eq_ref access for contant table
      optimization. Notice that eq_ref with a subquery
      providing the value is still possible during regular
      execution.
      2df19147
  19. 22 Aug, 2011 1 commit
  20. 20 Aug, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #826279. · aab970f5
      Igor Babaev authored
      When the WHERE/HAVING condition of a subquery has been transformed
      by the optimizer the pointer stored the 'where'/'having' field 
      of the SELECT_LEX structure used for the subquery must be updated
      accordingly. Otherwise the pointer may refer to an invalid item.
      This can lead to the reported assertion failure for some queries
      with correlated subqueries   
      aab970f5
  21. 17 Aug, 2011 1 commit
    • Sergey Petrunya's avatar
      BUG#826935 Assertion `!table || (!table->read_set ||... · e4bb5334
      Sergey Petrunya authored
      BUG#826935 Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed
      - add_ref_to_table_cond() should not just overwrite pre_idx_push_select_cond
        with the contents tab->select_cond.
        pre_idx_push_select_cond exists precisely for the reason that it may contain
        a condition that is a strict superset of what is in tab->select_cond. 
        The fix is to inject generated equality into pre_idx_push_select_cond.
      e4bb5334
  22. 16 Aug, 2011 1 commit
  23. 09 Aug, 2011 1 commit
    • unknown's avatar
      Fix bug lp:817384 · a6037394
      unknown authored
      This bug is a special case of lp:813447.
      
      Analysis:
      Constant optimization finds that the condition t2.a = 1
      can be used to access the primary key of table 't2'. As
      a result both outer table t1,t2 are considered as constant
      when we reach the execution phase. At the same time, during
      constant optimization, the IN predicate is not evaluated
      because it is expensive.
      
      When execution of the outer query reaches do_select(),
      control flow enter the branch:
      if (join->table_count == join->const_tables)
      { ... }
      This branch checks only the WHERE and HAVING clauses,
      but doesn't check the ON clauses of the query. Since the
      IN predicate was not evaluated during optimization, it is
      not evaluated at all, thus execution doesn't detect that
      the ON clause is FALSE.
      
      Solution:
      Similar to the patch for bug lp:813447, exclude system
      tables from constant substitution based on unique key
      lookups if there is an expensive ON condition on the
      inner table.
      a6037394
  24. 08 Aug, 2011 1 commit
    • Sergey Petrunya's avatar
      BUG#822134: Invalid plan and wrong result set for Q20 from DBT3 benchmark set · 81335120
      Sergey Petrunya authored
      - create_ref_for_key() has the code that walks KEYUSE array and tries to use
        maximum number of keyparts for ref (and eq_ref and ref_or_null) access.
        When one constructs ref access for table that is inside a SJ-Materialization
        nest, it is not possible to use tables that are ouside the nest (because 
        materialization is performed before they have any "current value").
        The bug was caused by this function not taking this into account.
      81335120
  25. 30 Jul, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #817360. · 103c4461
      Igor Babaev authored
      This problem could be observed for queries with nested outer joins
      for which the not_exist optimization were applicable. 
      The problem was caused by the code of the patch for bug #49322
      that erroneously forced the return to the previous nested loop
      level when the join algorithm successfully builds a partial record
      for an embedded outer to which the not_exist optimization could be
      applied.
      Actually the immediate return to the previous nested loops level
      is correct only if this partial record is rejected by a predicate
      pushed down to one of the inner tables of this outer join. Otherwise
      attempts to find extensions of this record must be made.
      103c4461
  26. 23 Jul, 2011 1 commit
  27. 21 Jul, 2011 2 commits
    • Igor Babaev's avatar
      Fixed LP bug #813447. · 4a03a1d7
      Igor Babaev authored
      Do not make substitution of a single-row table if it is an inner
      table of an outer join with on expression containing an expensive
      subquery.
      4a03a1d7
    • Igor Babaev's avatar
      Fixed LP bug #791761. · 2e8542f4
      Igor Babaev authored
      An aggregating query over an empty set of a join of two tables
      with a rejecting HAVING clause erroneously could return a row.
      It could happen in the cases when the optimizer made a conclusion
      that the aggregating set was empty.
      Wrong results were produced because the server missed initial
      setting for aggregation functions in the mentioned cases.
            
      2e8542f4
  28. 19 Jul, 2011 2 commits
    • Sergey Petrunya's avatar
      BUG##806524: Assertion `join->best_read < 1.7976931348623157e+308 with... · b11eff40
      Sergey Petrunya authored
      BUG##806524: Assertion `join->best_read < 1.7976931348623157e+308 with table_elimination=on and derived_merge=on 
      reset_nj_counters() used to rely on the fact that join nests have 
      table->table==NULL. This ceased to be true wit new derived table
      optimizations. Use test for table->nested_join!=NULL instead.
      b11eff40
    • unknown's avatar
      Fixed LP BUG#800696. · 99cce189
      unknown authored
      The problem was that optimizer removes some outer references (it they are
      constant for example) and the list of outer items built during prepare phase is
      not actual during execution phase when we need it as the cache parameters.
      First solution was use pointer on pointer on outer reference Item and
      initialize temporary table on demand. This solved most problem except case
      when optimiser also reduce Item which contains outer references ('OR' in
      this bug test suite).
      
      The solution is to build the list of outer reference items on execution
      phase (after optimization) on demand (just before temporary table creation)
      by walking Item tree and finding outer references among Item_ident
      (Item_field/Item_ref) and Item_sum items.
      
      Removed depends_on list (because it is not neede any mnore for the cache, in the place where it was used it replaced with upper_refs).
      
      Added processor (collect_outer_ref_processor) and get_cache_parameters() methods to collect outer references (or other expression parameters in future).
      
      mysql-test/r/subselect_cache.result:
        A new test added.
      mysql-test/r/subselect_scache.result:
        Changes in creating the cache and its paremeters order or adding arguments of aggregate function (which is a parameter also, but this has no influence on the result).
      mysql-test/t/subselect_cache.test:
        Added a new test.
      sql/item.cc:
        depends_on removed.
        
        Added processor (collect_outer_ref_processor) and get_cache_parameters() methods to collect outer references.
        
        Item_cache_wrapper collect parameters befor initialization of its cache.
      sql/item.h:
        depends_on removed.
        
        Added processor (collect_outer_ref_processor) and get_cache_parameters() methods to collect outer references.
      sql/item_cmpfunc.cc:
        depends_on removed.
        
        Added processor (collect_outer_ref_processor) to collect outer references.
      sql/item_cmpfunc.h:
        Added processor (collect_outer_ref_processor) to collect outer references.
      sql/item_subselect.cc:
        depends_on removed.
        Added processor get_cache_parameters() method to collect outer references.
      sql/item_subselect.h:
        depends_on removed.
        Added processor get_cache_parameters() method to collect outer references.
      sql/item_sum.cc:
        Added processor (collect_outer_ref_processor) method to collect outer references.
      sql/item_sum.h:
        Added processor (collect_outer_ref_processor) and get_cache_parameters() methods to collect outer references.
      sql/opt_range.cc:
        depends_on removed.
      sql/sql_base.cc:
        depends_on removed.
      sql/sql_class.h:
        New iterator added.
      sql/sql_expression_cache.cc:
        Build of list of items resolved in outer query done just before creating expression cache on the first execution of the subquery which removes influence of optimizer removing items (all optimization already done).
      sql/sql_expression_cache.h:
        Build of list of items resolved in outer query done just before creating expression cache on the first execution of the subquery which removes influence of optimizer removing items (all optimization already done).
      sql/sql_lex.cc:
        depends_on removed.
      sql/sql_lex.h:
        depends_on removed.
      sql/sql_list.h:
        Added add_unique method to add only unique elements to the list.
      sql/sql_select.cc:
        Support of new Item list added.
      sql/sql_select.h:
        Support of new Item list added.
      99cce189
  29. 18 Jul, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #793448. · a7287d9a
      Igor Babaev authored
      This bug could lead to wrong result sets for a query over a
      materialized derived table or view accessed by a multi-component
      key.
      It happened because the function get_next_field_for_derived_key
      was supposed to update its argument, and it did not do it.
      a7287d9a
  30. 17 Jul, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #794901. · d37465a9
      Igor Babaev authored
      Also:
      1. simplified the code of the function mysql_derived_merge_for_insert.
      2. moved merge of views/dt for multi-update/delete to the prepare stage.
      3. the list of the references to the candidates for semi-join now is
         allocated in the statement memory.
      d37465a9
  31. 14 Jul, 2011 2 commits
    • unknown's avatar
      Fix bug lp:777691 · 53681ee5
      unknown authored
      Analysis:
      
      For some of the re-executions of the correlated subquery the
      where clause is false. In these cases the execution of the
      subquery detects that it must generate a NULL row because of
      implicit grouping. In this case the subquery execution reaches
      the following code in do_select():
      
              while ((table= li++))
                mark_as_null_row(table->table);
      
      This code marks all rows in the table as complete NULL rows.
      In the example, when evaluating the field t2.f10 for the second
      row, all bits of Field::null_ptr[0] are set by the previous call
      to mark_as_null_row(). Then the call to Field::is_null()
      returns true, resulting in a NULL for the MAX function.
      
      Thus the lines above are not suitable for subquery re-execution
      because mark_as_null_row() changes the NULL bits of each table
      field, and there is no logic to restore these fields.
      
      Solution:
      
      The call to mark_as_null_row() was added by the fix for bug
      lp:613029. Therefore removing the fix for lp:613029 corrects
      this wrong result. At the same time the test for lp:613029
      behaves correctly because the changes of MWL#89 result in a
      different execution path where:
      - the constant subquery is evaluated via JOIN::exec_const_cond
      - detecting that it has an empty result triggers the branch
        if (zero_result_cause)
          return_zero_rows()
      - return_zero_rows() calls mark_as_null_row().
      
      53681ee5
    • Igor Babaev's avatar
  32. 13 Jul, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #809206. · 5819dfcd
      Igor Babaev authored
      The bitmap of used tables must be evaluated for the select list of every
      materialized derived table / view and saved in a dedicated field.
      This is also applied to materialized subqueries.
      5819dfcd
  33. 12 Jul, 2011 1 commit