An error occurred fetching the project authors.
  1. 30 Aug, 2013 1 commit
    • Igor Babaev's avatar
      Fixed bug mdev-4971. · 576a2b15
      Igor Babaev authored
      The function propagate_new_equalities() did not updated properly
      the references to inherited multiple equalities.
      576a2b15
  2. 26 Aug, 2013 1 commit
    • Igor Babaev's avatar
      Fixed bug mdev-4944. · 901737c9
      Igor Babaev authored
      The patch to fix mdev-4418 turned out to be incorrect.
      At the substitution of single row tables in make_join_statistics()
      the used multiple equalities may change and references to the new multiple
      equalities must be updated. The function remove_eq_conds() takes care of it and
      it should be called right after the substitution of single row tables.
      Calling it after the call of make_join_statistics was a mistake.
      901737c9
  3. 17 Aug, 2013 1 commit
    • Igor Babaev's avatar
      Fixed bug mdev-4418. · 25c15201
      Igor Babaev authored
      After single row substitutions there might appear new equalities.
      They should be properly propagated to all AND/OR levels the WHERE
      condition. It's done now with an additional call of remove_eq_conds(). 
      25c15201
  4. 15 Aug, 2013 1 commit
    • Igor Babaev's avatar
      Fixed bug mdev-4355. · fa7f6772
      Igor Babaev authored
      This patch almost totally revised the patch for bug mdev-4177.
      The latter had too many defects. In particular, it did not
      propagate multiple equalities formed when merging a degenerate
      disjunct into underlying AND formula.
      fa7f6772
  5. 08 May, 2013 1 commit
    • Alexander Barkov's avatar
      The bug · e013bf9f
      Alexander Barkov authored
      MDEV-4489 "Replication of big5, cp932, gbk, sjis strings makes wrong values on slave"
      has been fixed.
      
      Problem:
      String constants of some Asian charsets (big5,cp932,gbk,sjis)
      can have backslash '\' (0x5C) in the second byte of multi-byte characters.
      Replicating of such constants using the standard '\'-escaping is dangerous.
      Therefore, constants of these charsets are replicated using hex notation:
      INSERT INTO t1 (a) VALUES (0x815C);
      
      However, 0xHHHH constants do not work well in some cases,
      because they can behave as strings and as numbers, depending on context
      (for example, depending on the data type of the column in an INSERT statement).
      
      This SQL script was not replicated correctly with statement-based replication:
      
      SET NAMES gbk;
      PREPARE STMT FROM 'INSERT INTO t1 (a) VALUES (?)';
      SET @A = '1';
      EXECUTE STMT USING @A;
      
      The INSERT statement was replicated as:
      INSERT INTO t1 (a) VALUES (0x31);
      
      '1' was correctly converted to the number 1 on master.
      But the 0x31 constant was treated as number 49 on slave.
      
      Fix:
      
      1. Binary log now uses X'HHHH' instead of 0xHHHH constants.
      2. The X'HHHH' constants now work always as strings, in all contexts.
      This is the SQL standard compliant behaviour.
      
      After the fix, the above statement is replicated as:
      INSERT INTO t1 (a) VALUES (X'31');
      X'31' is treated as string '1' on slave, and is correctly converted to 1.
      
      
      modified:
        @ mysql-test/r/ctype_cp932_binlog_stm.result
        @ mysql-test/r/select.result
        @ mysql-test/r/select_jcl6.result
        @ mysql-test/r/select_pkeycache.result
        @ mysql-test/r/user_var-binlog.result
        @ mysql-test/r/varbinary.result
        @ mysql-test/suite/binlog/r/binlog_stm_ctype_ucs.result
        @ mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result
        @ mysql-test/suite/rpl/r/rpl_charset_sjis.result
        @ mysql-test/suite/rpl/r/rpl_mdev382.result
        @ mysql-test/suite/rpl/t/rpl_charset_sjis.test
        @ mysql-test/t/ctype_cp932_binlog_stm.test
        @ mysql-test/t/select.test
        @ mysql-test/t/varbinary.test
          Adding and updating tests
      
        @ sql/item.cc
        @ sql/item.h
        @ sql/sql_yacc.yy
        @ sql/sql_lex.cc
          Splitting the implementations of X'HH' and 0xHH constants into two
          separate classes. Fixing the parser to distinguish the two syntaxes.
      
        @ sql/log_event.cc
          Using X'HH' instead of 0xHH for binary logging for string constants
          of the "dangerous" charsets.
      
        @ sql/sql_string.h
          Adding a helped method String::append_hex().
      e013bf9f
  6. 30 Apr, 2013 1 commit
    • Igor Babaev's avatar
      Fixed bug mdev-4274. · 86f43c30
      Igor Babaev authored
      This bug was the result of incompleteness of the patch for bug mdev-4177.
      When an OR condition is simplified to a single conjunct it is merged
      into the embedding AND condition. Multiple equalities are also merged,
      and any field item involved in those equality should acquire a pointer
      to a the multiple equality formed by this merge.
      86f43c30
  7. 08 Mar, 2013 1 commit
    • Igor Babaev's avatar
      Fixed bug mdev-4250. · 926b0f54
      Igor Babaev authored
      This is a bug in the legacy code. It did not manifest itself because
      it was masked by other bugs that were fixed by the patches for
      mdev-4172 and mdev-4177.
      926b0f54
  8. 30 Sep, 2012 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #1058071 (mdev-564). · 66bd2b56
      Igor Babaev authored
      In some rare cases when the value of the system variable join_buffer_size
      was set to a number less than 256 the function JOIN_CACHE::set_constants 
      determined the size of an offset in the join buffer equal to 1 though
      the minimal join buffer required more than 256 bytes. This could cause
      a crash of the server when records from the join buffer were read.  
      66bd2b56
  9. 07 May, 2012 1 commit
    • unknown's avatar
      LP bug#994275 fix. · ea8314fd
      unknown authored
      In 5.3 we substitute constants in ref access values it can't be null so we do not need add NOT NULL for early NULL filtering.
      ea8314fd
  10. 18 Jan, 2012 1 commit
  11. 07 Jan, 2012 1 commit
  12. 24 Dec, 2011 1 commit
    • Igor Babaev's avatar
      Back-ported the patch of the mysql-5.6 code line that · 2b1f0b87
      Igor Babaev authored
      fixed several defects in the greedy optimization:
      
      1) The greedy optimizer calculated the 'compare-cost' (CPU-cost)
         for iterating over the partial plan result at each level in
         the query plan as 'record_count / (double) TIME_FOR_COMPARE'
      
         This cost was only used locally for 'best' calculation at each
         level, and *not* accumulated into the total cost for the query plan.
      
         This fix added the 'CPU-cost' of processing 'current_record_count'
         records at each level to 'current_read_time' *before* it is used as
         'accumulated cost' argument to recursive 
         best_extension_by_limited_search() calls. This ensured that the
         cost of a huge join-fanout early in the QEP was correctly
         reflected in the cost of the final QEP.
      
         To get identical cost for a 'best' optimized query and a
         straight_join with the same join order, the same change was also
         applied to optimize_straight_join() and get_partial_join_cost()
      
      2) Furthermore to get equal cost for 'best' optimized query and a
         straight_join the new code substrcated the same '0.001' in
         optimize_straight_join() as it had been already done in
         best_extension_by_limited_search()
      
      3) When best_extension_by_limited_search() aggregated the 'best' plan a
         plan was 'best' by the check :
      
         'if ((search_depth == 1) || (current_read_time < join->best_read))'
      
         The term '(search_depth == 1' incorrectly caused a new best plan to be
         collected whenever the specified 'search_depth' was reached - even if
         this partial query plan was more expensive than what we had already
         found.
      2b1f0b87
  13. 15 Dec, 2011 2 commits
  14. 12 Dec, 2011 1 commit
    • Sergei Golubchik's avatar
      after merge changes: · 2ccf247e
      Sergei Golubchik authored
      * rename all debugging related command-line options
        and variables to start from "debug-", and made them all
        OFF by default.
      * replace "MySQL" with "MariaDB" in error messages
      * "Cast ... converted ... integer to it's ... complement"
        is now a note, not a warning
      * @@query_cache_strip_comments now has a session scope,
        not global.
      2ccf247e
  15. 06 Nov, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #886145. · e0c1b3f2
      Igor Babaev authored
      The bug happened because in some cases the function JOIN::exec
      did not save the value of TABLE::pre_idx_push_select_cond in
      TABLE::select->pre_idx_push_select_cond for the sort table.
      
      Noticed and fixed a bug in the function make_cond_remainder
      that builds the remainder condition after extraction of an index
      pushdown condition from the where condition. The code
      erroneously assumed that the function make_cond_for_table left
      the value of ICP_COND_USES_INDEX_ONLY in sub-condition markers.
      Adjusted many result files from the regression test suite
      after this fix .
      e0c1b3f2
  16. 01 Oct, 2011 1 commit
  17. 22 Aug, 2011 1 commit
  18. 15 Jul, 2011 1 commit
  19. 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
  20. 02 Jul, 2011 1 commit
  21. 04 May, 2011 1 commit
  22. 25 Apr, 2011 1 commit
  23. 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
  24. 24 Feb, 2011 1 commit
    • Igor Babaev's avatar
      BNLH algorithm always used a full table scan over the joined table · 272e5e62
      Igor Babaev authored
      even in the cases when there existed range/index-merge scans that
      were cheaper than the full table scan.
      This was a defect/bug of the implementation of mwl #128. 
      Now hash join can work not only with full table scan of the joined
      table, but also with full index scan, range and index-merge scans.
      Accordingly, in the cases when hash join is used the column 'type'
      in the EXPLAINs can contain now 'hash_ALL', 'hash_index', 'hash_range'
      and 'hash_index_merge'. If hash join is coupled with a range/index_merge
      scan then the columns 'key' and 'key_len' contain info not only on
      the used hash index, but also on the indexes used for the scan.   
      272e5e62
  25. 26 Jan, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #707555. · a624f99e
      Igor Babaev authored
      The bug was in the code of the patch fixing bug 698882.
      With improper casting the method store_key_field::change_source_field
      was called for the elements of the array TABLE_REF::key_copy that
      were either of a different type or not allocated at all. This caused
      crashes in some queries. 
      a624f99e
  26. 16 Jan, 2011 1 commit
  27. 15 Jan, 2011 2 commits
    • Igor Babaev's avatar
      Fixed LP bug #698882. · 84a0c9b2
      Igor Babaev authored
      Made sure that the optimal fields are used by TABLE_REF objects
      when building index access keys to joined tables.
      Fixed a bug in the template function that sorts the elements of
      a list using the bubble sort algorithm. The bug caused poor
      performance of the function. Also added an optimization that
      skips comparison with the most heavy elements that has been 
      already properly placed in the list.
      Made the comparison of the fields belonging to the same Item_equal
      more granular: fields belonging to the same table are also ordered
      according to some rules.
      84a0c9b2
    • Igor Babaev's avatar
      Ported the fix for LP bug #702310 / bug #59493. · 0aebdc11
      Igor Babaev authored
      An assertion failure was triggered for a 6-way join query that used two
      join buffers.
      The failure happened because every call of JOIN_CACHE::join_matching_records
      saved and restored status of all tables that were accessed before the table
      join_tab. It must do it only for those of them that follow the last table 
      using a join buffer.
      0aebdc11
  28. 05 Jan, 2011 1 commit
  29. 18 Oct, 2010 1 commit
  30. 13 Oct, 2010 1 commit
  31. 28 Sep, 2010 1 commit
    • Igor Babaev's avatar
      Fixed bug #52636. · 21b1b5f0
      Igor Babaev authored
      Applied the fix for bug #47217 from the mysql-6.0 codebase.
      The patch adds not null predicates generated for the left parts
      of the equality predicates used for ref accesses. This is done
      for such predicates both in where conditions and on conditions.
      For the where conditions the not null predicates were generated
      but in 5.0/5.1 they actually never were used due to some lame
      merge from 4.1 to 5.0. The fix for bug #47217 made these 
      predicates to be used in the condition pushed to the tables.
      Yet only this patch generates not null predicates for equality
      predicated from on conditions of outer joins.
      This patch introduces a performance regression that can be
      observed on a test case from null_key.test. The regression
      will disappear after the fix for bug #57024 from mariadb-5.1
      is pulled into mariadb-5.3.
      The patch contains many changes in the outputs of the EXPLAIN 
      commands since generated not null predicates are considered as
      parts of the conditions pushed to join tables and may add
      'Usingwhere' in some rows of EXPLAINs where there used
      to be no such comments.
      21b1b5f0
  32. 15 Sep, 2010 1 commit
  33. 31 Aug, 2010 1 commit
  34. 21 Dec, 2009 1 commit
  35. 15 Dec, 2009 3 commits
    • Ramil Kalimullin's avatar
      Fix for bug#49517: Inconsistent behavior while using · c5e6a11e
      Ramil Kalimullin authored
      NULLable BIGINT and INT columns in comparison
      
      Problem: a consequence of the fix for 43668.
      Some Arg_comparator inner initialization missed,
      that may lead to unpredictable (wrong) comparison
      results.
      
      Fix: always properly initialize Arg_comparator
      before its usage.
      
      
      mysql-test/r/select.result:
        Fix for bug#49517: Inconsistent behavior while using 
        NULLable BIGINT and INT columns in comparison
          -test result.
      mysql-test/t/select.test:
        Fix for bug#49517: Inconsistent behavior while using 
        NULLable BIGINT and INT columns in comparison
          -test case.
      sql/item_cmpfunc.cc:
        Fix for bug#49517: Inconsistent behavior while using 
        NULLable BIGINT and INT columns in comparison
          - now all Arg_comparator::set_cmp_func() set
        Arg_comparator::set_null to ensure its proper initialization
        in all cases (by default it's set to TRUE in constructors).
      sql/item_cmpfunc.h:
        Fix for bug#49517: Inconsistent behavior while using 
        NULLable BIGINT and INT columns in comparison
          - now all Arg_comparator::set_cmp_func() set
        Arg_comparator::set_null to ensure its proper initialization
        in all cases (by default it's set to TRUE in constructors).
      c5e6a11e
    • Georgi Kodinov's avatar
      Bug#49489: Uninitialized cache led to a wrong result. · 838adcf2
      Georgi Kodinov authored
      Merge the fix from 5.1-bugteam to 5.1-main
      838adcf2
    • Sergey Petrunya's avatar
      Backport into MariaDB-5.2 the following: · 96e092dc
      Sergey Petrunya authored
      WL#2474 "Multi Range Read: Change the default MRR implementation to implement new MRR interface"
      WL#2475 "Batched range read functions for MyISAM/InnoDb"
              "Index condition pushdown for MyISAM/InnoDB"
      Igor's fix from sp1r-igor@olga.mysql.com-20080330055902-07614:
        There could be observed the following problems:
        1. EXPLAIN did not mention pushdown conditions from on expressions in the 
        'extra' column.  As a result if a query had no where conditions pushed 
        down to a table, but had on conditions pushed to this table the 'extra' 
        column in the EXPLAIN for the table missed 'using where'.
        2. Conditions for ref access were not eliminated from on expressions 
        though such conditions were eliminated from the where condition.
      96e092dc
  36. 11 Dec, 2009 1 commit