1. 06 Mar, 2013 2 commits
  2. 01 Mar, 2013 2 commits
  3. 28 Feb, 2013 7 commits
    • Igor Babaev's avatar
      Fixed bug mdev-4209 · 90c0f3d3
      Igor Babaev authored
      Do not include BLOB fields into the key to access the temporary
      table created for a materialized view/derived table.
      BLOB components are not allowed in keys. 
      90c0f3d3
    • Sergei Golubchik's avatar
      5.2 -> 5.3 · c4341d50
      Sergei Golubchik authored
      c4341d50
    • Sergei Golubchik's avatar
      5.1 -> 5.2 merge · 5dec570d
      Sergei Golubchik authored
      5dec570d
    • Igor Babaev's avatar
      Fixed a compile error for some platform. · 0d55ebc0
      Igor Babaev authored
      0d55ebc0
    • Sergei Golubchik's avatar
      a simpler fix for · 027e34e1
      Sergei Golubchik authored
      MySQL Bug #12408412: GROUP_CONCAT + ORDER BY + INPUT/OUTPUT SAME USER VARIABLE = CRASH
      and
      MySQL Bug#14664077 SEVERE PERFORMANCE DEGRADATION IN SOME CASES WHEN USER VARIABLES ARE USED
      
      
      sql/item_func.cc:
        don't use anything from Item_func_set_user_var::fix_fields()
        in Item_func_set_user_var::save_item_result()
      sql/sql_class.cc:
        Call suv->save_item_result(item) *before* doing suv->fix_fields(), because
        the former evaluates the item (and caches its value), while the latter marks
        the user variable as non-const. The problem is that the item was fix_field'ed
        when the user variable was const, and it doesn't expect it to change to non-const
        in the middle of the execution.
      027e34e1
    • Michael Widenius's avatar
    • Sergei Golubchik's avatar
      mysql-5.1 merge · 08ba2578
      Sergei Golubchik authored
      mysys/errors.c:
        revert upstream's fix. use a much simpler one
      mysys/my_write.c:
        revert upstream's fix. use a simpler one
      sql/item_xmlfunc.cc:
        useless, but ok
      sql/mysqld.cc:
        simplify upstream's fix
      storage/heap/hp_delete.c:
        remove upstream's fix.
        we'll use a much less expensive approach.
      08ba2578
  4. 26 Feb, 2013 1 commit
  5. 25 Feb, 2013 1 commit
    • Igor Babaev's avatar
      Fixed bug mdev-4177 · d434d79a
      Igor Babaev authored
      The function remove_eq_cond removes the parts of a disjunction
      for which it has been proved that they are always true. In the
      result of this removal the disjunction may be converted into a 
      formula without OR that must be merged into the the AND formula
      that contains the disjunction.
      The merging of two AND conditions must take into account the
      multiple equalities that may be part of each of them.
      These multiple equality must be merged and become part of the
      and object built as the result of the merge of the AND conditions.
      Erroneously the function remove_eq_cond lacked the code that 
      would merge multiple equalities of the merged AND conditions.
      This could lead to confusing situations when at the same AND 
      level there were two multiple equalities with common members
      and the list of equal items contained only some of these 
      multiple equalities.
      This, in its turn, could lead to an incorrect work of the
      function substitute_for_best_equal_field when it tried to optimize
      ref accesses. This resulted in forming invalid TABLE_REF objects
      that were used to build look-up keys when materialized subqueries
      were exploited.
         
      d434d79a
  6. 22 Feb, 2013 1 commit
    • Igor Babaev's avatar
      Fixed bug mdev-4172. · ed7671d5
      Igor Babaev authored
      This bug in the legacy code could manifest itself in queries with
      semi-join materialized subqueries.
      When a subquery is materialized all conditions that are imposed
      only on the columns belonging to the tables from the subquery 
      are taken into account.The code responsible for subquery optimizations
      that employes subquery materialization  makes sure to remove these
      conditions from the WHERE conditions of the query obtained after
      it has transformed the original query into a query with a semi-join.
      If the condition to be removed is an equality condition it could
      be added to ON expressions and/or conditions from disjunctive branches
      (parts of OR conditions) in an attempt to generate better access keys
      to the tables of the query. Such equalities are supposed to be removed
      later from all the formulas where they have been added to.
      However, erroneously, this was not done in some cases when an ON
      expression and/or a disjunctive part of the OR condition could
      be converted into one multiple equality. As a result some equality
      predicates over columns belonging to the tables of the materialized
      subquery remained in the ON condition and/or the a disjunctive 
      part of the OR condition, and the excuter later, when trying to
      evaluate them, returned wrong answers as the values of the fields
      from these equalities were not valid.  
      This happened because any standalone multiple equality (a multiple
      equality that are not ANDed with any other predicates) lacked
      the information about equality predicates inherited from upper
      levels (in particular, inherited from the WHERE condition).
      The fix adds a reference to such information to any standalone
      multiple equality. 
      ed7671d5
  7. 21 Feb, 2013 3 commits
    • Vladislav Vaintroub's avatar
    • Igor Babaev's avatar
      Merge. · 6537b551
      Igor Babaev authored
      6537b551
    • Igor Babaev's avatar
      Fixed bug mdev-3913. · c9b63e6a
      Igor Babaev authored
      The wrong result set returned by the left join query  from
      the bug test case happened due to several inconsistencies 
      and bugs of the legacy mysql code.
      
      The bug test case uses an execution plan that employs a scan
      of a materialized IN subquery from the WHERE condition.
      When materializing such an IN- subquery the optimizer injects
      additional equalities  into the WHERE clause. These equalities
      express the constraints imposed by the subquery predicate.
      The injected equality of the query in the  test case happens
      to belong to the same equality class, and a new equality 
      imposing a condition on the rows of the materialized subquery
      is inferred from this class. Simultaneously the multiple
      equality is added to the ON expression of the LEFT JOIN
      used in the main query.
        
      The inferred equality of the form f1=f2 is taken into account
      when optimizing the scan of  the rows the temporary table 
      that is the result of the subquery materialization: only the 
      values of the field f1 are read from the table into the record 
      buffer. Meanwhile the inferred equality is removed from the
      WHERE conditions altogether as a constraint on the fields
      of the temporary table that has been used when filling this table. 
      This equality is supposed to be removed from the ON expression
      when the multiple equalities of the ON expression are converted
      into an optimal set of equality predicates. It supposed to be
      removed from the ON expression as an equality inferred from only
      equalities of the WHERE condition. Yet, it did not happened
      due to the following bug in the code.
      
      Erroneously the code tried to build multiple equality for ON
      expression twice: the first time, when it called optimize_cond()
      for the WHERE condition, the second time, when it called
      this function for the HAVING condition. When executing
      optimize_con() for the WHERE condition  a reference
      to the multiple equality of the WHERE condition is set
      in the multiple equality of the  ON expression. This reference
      would allow later to convert multiple equalities of the
      ON expression into equality predicates. However the 
      the second call of build_equal_items() for the ON expression
      that happened when optimize_cond() was called for the
      HAVING condition reset this reference to NULL.
      
      This bug fix blocks calling build_equal_items() for ON
      expressions for the second time. In general, it will be
      beneficial for many queries as it removes from ON 
      expressions any equalities that are to be checked for the
      WHERE condition.
      The patch also fixes two bugs in the list manipulation
      operations and a bug in the function  
      substitute_for_best_equal_field() that resulted
      in passing wrong reference to the multiple equalities
      of where conditions when processing multiple
      equalities  of ON expressions.
      
      The code of substitute_for_best_equal_field() and
      the code the helper function eliminate_item_equal()
      were also streamlined and cleaned up.
      Now the conversion of the multiple equalities into
      an optimal set of equality predicates first produces
      the sequence of the all equalities processing multiple
      equalities one by one, and, only after this, it inserts
      the equalities at the beginning of the other conditions.
      
      The multiple changes in the output of EXPLAIN
      EXTENDED are mainly the result of this streamlining,
      but in some cases is the result of the removal of
      unneeded equalities from ON expressions. In
      some test cases this removal were reflected in the
      output of EXPLAIN resulted in disappearance of 
      “Using where” in some rows of the execution plans.
      c9b63e6a
  8. 14 Feb, 2013 1 commit
  9. 13 Feb, 2013 1 commit
    • unknown's avatar
      Fix for MDEV-4140 · d4b1e8f3
      unknown authored
      Analysis:
      Range analysis detects that the subquery is expensive and doesn't
      build a range access method. Later, the applicability test for loose
      scan doesn't take that into account, and builds a loose scan method
      without a range scan on the min/max column. As a result loose scan
      fetches the first key in each group, rather than the first key that
      satisfies the condition on the min/max column.
      
      Solution:
      Since there is no SEL_ARG tree to be used for the min/max column,
      it is not possible to use loose scan if the min/max column is compared
      with an expensive scalar subquery. Make the test for loose scan
      applicability to be in sync with the range analysis code by testing if
      the min/max argument is compared with an expensive predicate.
      d4b1e8f3
  10. 12 Feb, 2013 1 commit
  11. 11 Feb, 2013 1 commit
    • unknown's avatar
      MDEV-4123 fix. · 3f36dfe3
      unknown authored
      Missed update_used_tables() call for multi-update values.
      3f36dfe3
  12. 08 Feb, 2013 1 commit
    • Igor Babaev's avatar
      Fixed bug mdev-3995. · 48aee459
      Igor Babaev authored
      This bug happened because the executor tried to use a wrong
      TABLE REF object when building access keys. It constructed
      keys from fields of a materialized table from a ref object
      created to construct keys from the fields of the underlying
      base table. This could happen only when materialized table
      was created for a non-correlated IN subquery and only
      when the materialized table used for lookups.
      In this case we are guaranteed to be able to construct the
      keys from the fields of tables that would be outer tables
      for the tables of the IN subquery.
      The patch makes sure that no ref objects constructed from
      fields of materialized lookup tables are to be used.
      48aee459
  13. 04 Feb, 2013 1 commit
    • unknown's avatar
      Fix for bug MDEV-765 (LP:825075) · 0b2dc3fc
      unknown authored
      Analys:
      The cause for the wrong result was that the optimizer
      incorrectly chose min/max loose scan when it is not
      applicable. The applicability test missed the case when
      a condition on the MIN/MAX argument was OR-ed with a
      condition on some other field. In this case, the MIN/MAX
      condition cannot be used for loose scan.
      
      Solution:
      Extend the test check_group_min_max_predicates() to check
      that the WHERE clause is of the form: "cond1 AND cond2"
      where 
        cond1 - does not use min_max_column at all.
        cond2 - is an AND/OR tree with leaves in form "min_max_column $CMP$ const"
                or $CMP$ is one of the functions between, is [not] null
      
      0b2dc3fc
  14. 31 Jan, 2013 1 commit
    • unknown's avatar
      Fix bug MDEV-641 · 768b62fe
      unknown authored
      Analysis:
      Range analysis discoveres that the query can be executed via loose index scan for GROUP BY.
      Later, GROUP BY analysis fails to confirm that the GROUP operation can be computed via an
      index because there is no logic to handle duplicate field references in the GROUP clause.
      As a result the optimizer produces an inconsistent plan. It constructs a temporary table,
      but on the other hand the group fields are not set to point there.
          
      Solution:
      Make loose scan analysis work in sync with order by analysis. In the case of duplicate
      columns loose scan will not be applicable. This limitation will be lifted in 10.0 by
      removing duplicate columns.
      768b62fe
  15. 28 Jan, 2013 2 commits
  16. 26 Jan, 2013 1 commit
  17. 25 Jan, 2013 7 commits
  18. 24 Jan, 2013 2 commits
  19. 22 Jan, 2013 1 commit
  20. 21 Jan, 2013 3 commits
    • Igor Babaev's avatar
      Merge 5.1->5.2 · 8127e631
      Igor Babaev authored
      8127e631
    • Igor Babaev's avatar
      Merge. · 82fe8a4e
      Igor Babaev authored
      82fe8a4e
    • Igor Babaev's avatar
      Fixed bug mdev-4063 (bug #56927). · fade3647
      Igor Babaev authored
      This bug could result in returning 0 for the expressions of the form 
      <aggregate_function>(distinct field) when the system variable  
      max_heap_table_size was set to a small enough number.
      It happened because the method Unique::walk() did not support
      the case when more than one pass was needed to merge the trees
      of distinct values saved in an external file.
      
      Backported a fix in grant_lowercase.test from mariadb 5.5.
      fade3647