An error occurred fetching the project authors.
  1. 13 Mar, 2013 1 commit
    • Sergei Golubchik's avatar
      MDEV-4265 5.5 is slower than 5.3 because of many str_to_datetime calls · 372bc22b
      Sergei Golubchik authored
      get_datetime_value() should not double-cache its own Item_cache_temporal items,
      but it *should* cache other Item_cache items, such as Item_cache_str.
      
      sql/item.h:
        shortcut, to avoid going through the switch in Item::cmp_type()
      sql/item_cmpfunc.cc:
        even if the item is Item_cache_str - it still needs to be converted and cached.
      sql/item_timefunc.h:
        all descendants of Item_temporal_func always have cmp_type==TIME_RESULT.
        Even Item_date_add_interval, that might have field_type == MYSQL_TYPE_STRING.
      372bc22b
  2. 11 Mar, 2013 1 commit
  3. 25 Feb, 2013 2 commits
    • unknown's avatar
      [NOT] EXISTS to IN transformation. · e3ac3061
      unknown authored
      e3ac3061
    • 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
  4. 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
  5. 28 Dec, 2012 1 commit
    • unknown's avatar
      MDEV-3873 & MDEV-3876 & MDEV-3912 : Wrong result (extra rows) with ALL subquery · 6f26aac9
      unknown authored
      from a MERGE view.
      
      The problem was in the lost ability to be null for the table of a left join if it
      is a view/derived table.
      
      It hapenned because setup_table_map(), was called earlier then we merged
      the view or derived.
      
      Fixed by propagating new maybe_null flag during Item::update_used_tables().
      
      Change in join_outer.test and join_outer_jcl6.test appeared because
      IS NULL reported no used tables (i.e. constant) for argument which could not be
      NULL and new maybe_null flag was propagated for IS NULL argument (Item_field)
      because table the Item_field belonged to changed its maybe_null status.
      6f26aac9
  6. 23 Dec, 2012 1 commit
  7. 21 Dec, 2012 1 commit
    • Roy Lyseng's avatar
      Bug#15972635: Incorrect results returned in 32 table join with HAVING · 96c373c5
      Roy Lyseng authored
      The problem is a shift operation that is not 64-bit safe.
      The consequence is that used tables information for a join with 32 tables
      or more will be incorrect.
      
      Fixed by adding a type cast in Item_sum::update_used_tables().
      
      Also used the opportunity to fix some other potential bugs by adding an
      explicit type-cast to an integer in a left-shift operation.
      Some of them were quite harmless, but was fixed in order to get the same
      signed-ness as the other operand of the operation it was used in.
      
      sql/item_cmpfunc.cc
        Adjusted signed-ness for some integers in left-shift.
      
      sql/item_subselect.cc
        Added type-cast to nesting_map (which is a 32/64 bit type, so
        potential bug for deeply nested queries).
      
      sql/item_sum.cc
        Added type-cast to nesting_map (32/64-bit type) and table_map
        (64-bit type).
      
      sql/opt_range.cc
        Added type-cast to ulonglong (which is a 64-bit type).
      
      sql/sql_base.cc
        Added type-cast to nesting_map (which is a 32/64-bit type).
      
      sql/sql_select.cc
        Added type-cast to nesting_map (32/64-bit type) and key_part_map
        (64-bit type).
      
      sql/strfunc.cc
        Changed type-cast from longlong to ulonglong, to preserve signed-ness.
      96c373c5
  8. 19 Dec, 2012 1 commit
    • unknown's avatar
      MDEV-3928: Assertion `example' failed in Item_cache::is_expensive_processor... · e99aa91e
      unknown authored
      MDEV-3928: Assertion `example' failed in Item_cache::is_expensive_processor with a 2-level IN subquery
      
      Analysis:
      The following call stack shows that it is possible to set Item_cache::value_cached, and the relevant value
      without setting Item_cache::example.
      
      #0 Item_cache_temporal::store_packed at item.cc:8395
      #1 get_datetime_value at item_cmpfunc.cc:915
      #2 resolve_const_item at item.cc:7987
      #3 propagate_cond_constants at sql_select.cc:12264
      #4 propagate_cond_constants at sql_select.cc:12227
      #5 optimize_cond at sql_select.cc:13026
      #6 JOIN::optimize at sql_select.cc:1016
      #7 st_select_lex::optimize_unflattened_subqueries at sql_lex.cc:3161
      #8 JOIN::optimize_unflattened_subqueries at opt_subselect.cc:4880
      #9 JOIN::optimize at sql_select.cc:1554
      
      The fix is to set Item_cache_temporal::example even when the value is
      set directly by Item_cache_temporal::store_packed. This makes the
      Item_cache_temporal object consistent.
      e99aa91e
  9. 28 Sep, 2012 1 commit
  10. 25 Sep, 2012 1 commit
    • Tor Didriksen's avatar
      Backport · b079b388
      Tor Didriksen authored
      Bug #11764313 57135: CRASH IN ITEM_FUNC_CASE::FIND_ITEM WITH CASE WHEN
      Bug #11764818 57692: Crash in item_func_in::val_int() with ZEROFILL
      b079b388
  11. 21 Jun, 2012 1 commit
    • unknown's avatar
      Fix for LP bug#1001505 and LP bug#1001510 · 60561ae6
      unknown authored
      We set correct cmp_context during preparation to avoid changing it later by Item_field::equal_fields_propagator.
      (see mysql bugs #57135 #57692 during merging)
      60561ae6
  12. 15 Jun, 2012 1 commit
  13. 30 May, 2012 1 commit
    • unknown's avatar
      Fix for bug lp:1006231 · 66dfceb1
      unknown authored
      Analysis:
      
      When a subquery that needs a temp table is executed during
      the prepare or optimize phase of the outer query, at the end
      of the subquery execution all the JOIN_TABs of the subquery
      are replaced by a new JOIN_TAB that selects from the temp table.
      However that temp table has no corresponding TABLE_LIST.
      Once EXPLAIN execution reaches its last phase, it tries to print
      the names of the subquery tables through its TABLE_LISTs, but in
      the case of this bug there is no such TABLE_LIST (it is NULL),
      hence a crash.
      
      Solution:
      The fix is to block subquery evaluation inside
      Item_func_like::fix_fields and Item_func_like::select_optimize()
      using the Item::is_expensive() test.
      66dfceb1
  14. 25 May, 2012 1 commit
  15. 24 May, 2012 1 commit
    • unknown's avatar
      Test case for bug lp:1001117, MySQL BUG#12330344 · 4fa89b5f
      unknown authored
      Analysis:
      The problem in the original MySQL bug is that the range optimizer
      performs its analysis in a separate MEM_ROOT object that is freed
      after the range optimzier is done. During range analysis get_mm_tree
      calls Item_func_like::select_optimize, which in turn evaluates its
      right argument. In the test case the right argument is a subquery.
      
      In MySQL, subqueries are optimized lazyly, thus the call to val_str
      triggers optimization for the subquery. All objects needed by the
      subquery plan end up in the temporary MEM_ROOT used by the range
      optimizer. When execution ends, the JOIN::cleanup process tries to
      cleanup objects of the subquery plan, but all these objects are gone
      with the temporary MEM_ROOT. The solution for MySQL is to switch the
      mem_root.
      
      In MariaDB with the patch for bug lp:944706, all constant subqueries
      that may be used by the optimization process are preoptimized. Therefore
      Item_func_like::select_optimize only triggers subquery execution, and
      the above problem is not present.
      
      The patch however adds a test whether the evaluated right argument of
      the LIKE predicate is expensive. This is consistent with our approach
      not to evaluate expensive expressions during optimization.
      4fa89b5f
  16. 22 May, 2012 1 commit
  17. 17 May, 2012 3 commits
    • unknown's avatar
      Fix for bug lp:944706, task MDEV-193 · da521483
      unknown authored
      The patch enables back constant subquery execution during
      query optimization after it was disabled during the development
      of MWL#89 (cost-based choice of IN-TO-EXISTS vs MATERIALIZATION).
      
      The main idea is that constant subqueries are allowed to be executed
      during optimization if their execution is not expensive.
      
      The approach is as follows:
      - Constant subqueries are recursively optimized in the beginning of
        JOIN::optimize of the outer query. This is done by the new method
        JOIN::optimize_constant_subqueries(). This is done so that the cost
        of executing these queries can be estimated.
      - Optimization of the outer query proceeds normally. During this phase
        the optimizer may request execution of non-expensive constant subqueries.
        Each place where the optimizer may potentially execute an expensive
        expression is guarded with the predicate Item::is_expensive().
      - The implementation of Item_subselect::is_expensive has been extended
        to use the number of examined rows (estimated by the optimizer) as a
        way to determine whether the subquery is expensive or not.
      - The new system variable "expensive_subquery_limit" controls how many
        examined rows are considered to be not expensive. The default is 100.
      
      In addition, multiple changes were needed to make this solution work
      in the light of the changes made by MWL#89. These changes were needed
      to fix various crashes and wrong results, and legacy bugs discovered
      during development.
      da521483
    • unknown's avatar
      fix of LP bug#998321 · 5a474139
      unknown authored
      The problem is that we can't check null_value field of non-basic constant without the item execution.:
      5a474139
    • Mayank Prasad's avatar
      Bug#11766101 : 59140: LIKE CONCAT('%',@A,'%') DOESN'T MATCH WHEN @A CONTAINS LATIN1 STRING · 0581d1c4
      Mayank Prasad authored
      Issue/Cause:
      Issue is of memory corruption.During optimization phase, pattern to be matched in where 
      clause, is prepared. This is done in Item_func_concat::val_str() function which forms the
      resultant string (tmp_value) and return its pointer. In caller, Item_func_like::fix_fields, 
      pattern is made to point to this string (tmp_value). In further processing, tmp_value is 
      getting modified which causes pattern to have changed/wrong values.
      
      Fix:
      Allocate its own memroy location in caller, copy value of resultant string (tmp_value) 
      into that and make pattern to point to that. This makes sure no further changes to 
      tmp_value will affect pattern.
      
      0581d1c4
  18. 26 Mar, 2012 1 commit
  19. 28 Feb, 2012 1 commit
  20. 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
  21. 25 Jan, 2012 1 commit
    • Tor Didriksen's avatar
      Bug#13463415 63502: INCORRECT RESULTS OF BIGINT AND DECIMAL COMPARISON · 042bd151
      Tor Didriksen authored
      Bug#11758543 50756: BIGINT '100' MATCHES 1.001E2
      
      Expressions of the form
            BIGINT_COL <compare> <non-integer constant>
      
            should be done either as decimal, or float.
      
            Currently however, such comparisons are done as int,
            which means that the constant may be truncated,
            and yield false positives/negatives for all queries
            where compare is '>' '<' '>=' '<=' '=' '!='.
      
            BIGINT_COL IN <list of contstants>
            and
            BIGINT_COL BETWEEN <constant> AND <constant>
            are also affected.
      
      
      
      mysql-test/r/bigint.result:
        New tests.
      mysql-test/r/func_in.result:
        BIGINT <=> string comparison should be done as float,
        so a warning for the value 'abc' is appropriate.
      mysql-test/t/bigint.test:
        New tests.
      sql/item_cmpfunc.cc:
        In convert_constant_item() we verify that the constant item
        can be stored in the given field.
        For BIGINT columns (MYSQL_TYPE_LONGLONG) we must verify that the
        stored constant value is actually comparable as int,
        i.e. that the value was not truncated.
        
        For between: compare as int only if both arguments convert correctly to int.
      042bd151
  22. 19 Jan, 2012 1 commit
    • 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
  23. 13 Nov, 2011 1 commit
  24. 01 Nov, 2011 1 commit
  25. 26 Oct, 2011 1 commit
  26. 02 Nov, 2011 1 commit
  27. 23 Oct, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #879882. · 391c5db1
      Igor Babaev authored
      This bug happened because the function Item_cond::eval_not_null_tables
      erroneously did not initialize the value of not_null_tables_cache.
      391c5db1
  28. 18 Oct, 2011 1 commit
  29. 13 Oct, 2011 1 commit
  30. 22 Sep, 2011 1 commit
  31. 07 Sep, 2011 1 commit
  32. 05 Sep, 2011 1 commit
    • unknown's avatar
      Fix of LP BUG#780386. · 8b062c1f
      unknown authored
        
        ALL subquery should return TRUE if subquery rowa set is empty independently
        of left part.  The problem was that Item_func_(eq,ne,gt,ge,lt,le) do not
        call execution of second argument if first is NULL no in this case subquery
        will not be executed and when Item_func_not_all calls any_value() of the
        subquery or aggregation function which report that there was rows. So for
        NULL < ALL (SELECT...) result was FALSE instead of TRUE.
        
        Fix is just swapping of arguments of Item_func_(eq,ne,gt,ge,lt,le) (with
        changing the operation if it is needed) so that result will be the same
        (for examole a < b is equal to b > a). This fix exploit the fact that
        first argument will be executed in any case.
      8b062c1f
  33. 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
  34. 23 Aug, 2011 1 commit
    • unknown's avatar
      Fixed bug lp:825018 · c1a6dbe5
      unknown authored
      Analysis:
      During the first execution of the query through the stored
      procedure, the optimization phase calls
      substitute_for_best_equal_field(), which calls
      Item_in_optimizer::transform(). The latter replaces
      Item_in_subselect::left_expr with args[0] via assignment.
      In this test case args[0] is an Item_outer_ref which is
      created/deallocated for each re-execution. As a result,
      during the second execution Item_in_subselect::left_expr
      pointed to freed memory, which resulted in a crash.
      
      Solution:
      The solution is to use change_item_tree(), so that the
      origianal left expression is restored after each execution.
      c1a6dbe5
  35. 19 Aug, 2011 1 commit
  36. 17 Aug, 2011 1 commit
    • unknown's avatar
      Fix bug lp:813473 · 6b70cc53
      unknown authored
      The bug is a duplicate of MySQL's Bug#11764086,
      however MySQL's fix is incomplete for MariaDB, so
      this fix is slightly different.
      
      In addition, this patch renames
      Item_func_not_all::top_level() to is_top_level_item()
      to make it in line with the analogous methods of
      Item_in_optimizer, and Item_subselect.
      
      Analysis:
      It is possible to determine whether a predicate is
      NULL-rejecting only if it is a top-level one. However,
      this was not taken into account for Item_in_optimizer.
      As a result, a NOT IN predicate was erroneously
      considered as NULL-rejecting, and the NULL-complemented
      rows generated by the outer join were rejected before
      being checked by the NOT IN predicate.
      
      Solution:
      Change Item_in_optimizer to be considered as
      NULL-rejecting only if it a top-level predicate.
      6b70cc53
  37. 20 Jul, 2011 1 commit
    • unknown's avatar
      Fix of LP BUG#780386. · 2b6a2344
      unknown authored
      ALL subquery should return TRUE if subquery rowa set is empty independently
      of left part.  The problem was that Item_func_(eq,ne,gt,ge,lt,le) do not
      call execution of second argument if first is NULL no in this case subquery
      will not be executed and when Item_func_not_all calls any_value() of the
      subquery or aggregation function which report that there was rows. So for
      NULL < ALL (SELECT...) result was FALSE instead of TRUE.
      
      Fix is just swapping of arguments of Item_func_(eq,ne,gt,ge,lt,le) (with
      changing the operation if it is needed) so that result will be the same
      (for examole a < b is equal to b > a). This fix exploit the fact that
      first argument will be executed in any case.
      
      mysql-test/r/subselect.result:
        The test suite added.
      mysql-test/r/subselect_no_mat.result:
        The test suite added.
      mysql-test/r/subselect_no_opts.result:
        The test suite added.
      mysql-test/r/subselect_no_semijoin.result:
        The test suite added.
      mysql-test/r/subselect_scache.result:
        The test suite added.
      mysql-test/t/subselect.test:
        The test suite added.
      sql/item_cmpfunc.cc:
        Swap arguments creation methods added.
      sql/item_cmpfunc.h:
        Swap arguments creation methods added.
      sql/item_subselect.cc:
        Swap arguments of the comparison.
      2b6a2344