An error occurred fetching the project authors.
  1. 18 Jan, 2012 1 commit
  2. 07 Jan, 2012 1 commit
  3. 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
  4. 15 Dec, 2011 2 commits
  5. 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
  6. 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
  7. 01 Oct, 2011 1 commit
  8. 22 Aug, 2011 1 commit
  9. 15 Jul, 2011 1 commit
  10. 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
  11. 02 Jul, 2011 1 commit
  12. 04 May, 2011 1 commit
  13. 25 Apr, 2011 1 commit
  14. 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
  15. 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
  16. 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
  17. 16 Jan, 2011 1 commit
  18. 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
  19. 05 Jan, 2011 1 commit
  20. 18 Oct, 2010 1 commit
  21. 13 Oct, 2010 1 commit
  22. 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
  23. 15 Sep, 2010 1 commit
  24. 31 Aug, 2010 1 commit
  25. 21 Dec, 2009 1 commit
  26. 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
  27. 11 Dec, 2009 1 commit
  28. 09 Dec, 2009 1 commit
    • Evgeny Potemkin's avatar
      Bug#49489: Uninitialized cache led to a wrong result. · 1285ecd4
      Evgeny Potemkin authored
      Arg_comparator uses Item_cache objects to store constants being compared when
      they're need a type conversion. Because this cache wasn't initialized properly
      Arg_comparator might produce wrong comparison result.
      
      The Arg_comparator::cache_converted_constant function now initializes cache
      prior to usage.
      
      mysql-test/r/select.result:
        Added a test case for he bug#49489.
      mysql-test/t/select.test:
        Added a test case for he bug#49489.
      sql/item_cmpfunc.cc:
        Bug#49489: Uninitialized cache led to a wrong result.
        The Arg_comparator::cache_converted_constant function now initializes cache
        prior to usage.
      1285ecd4
  29. 04 Dec, 2009 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug#49199: Optimizer handles incorrectly: · f5b51bc1
      Ramil Kalimullin authored
      field='const1' AND field='const2' in some cases
      
      Building multiple equality predicates containing
      a constant which is compared as a datetime (with a field)
      we should take this fact into account and compare the 
      constant with another possible constatns as datetimes 
      as well.
      
      E.g. for the
      SELECT ... WHERE a='2001-01-01' AND a='2001-01-01 00:00:00'
      we should compare '2001-01-01' with '2001-01-01 00:00:00' as
      datetimes but not as strings.
      
      
      mysql-test/r/select.result:
        Fix for bug#49199: Optimizer handles incorrectly: 
        field='const1' AND field='const2' in some cases
          - test result.
      mysql-test/t/select.test:
        Fix for bug#49199: Optimizer handles incorrectly: 
        field='const1' AND field='const2' in some cases
          - test case.
      sql/item_cmpfunc.cc:
        Fix for bug#49199: Optimizer handles incorrectly: 
        field='const1' AND field='const2' in some cases
          - adding a constant to Item_equal compare it as
        a datetime value with stored one if there's a 
        date[time] field in a equality predicate.
      sql/item_cmpfunc.h:
        Fix for bug#49199: Optimizer handles incorrectly: 
        field='const1' AND field='const2' in some cases
          - adding a constant to Item_equal compare it as
        a datetime value with stored one if there's a 
        date[time] field in a equality predicate.
      sql/sql_select.cc:
        Fix for bug#49199: Optimizer handles incorrectly: 
        field='const1' AND field='const2' in some cases
          - adding a constant to Item_equal compare it as
        a datetime value with stored one if there's a 
        date[time] field in a equality predicate.
      f5b51bc1
  30. 01 Dec, 2009 1 commit
    • Evgeny Potemkin's avatar
      Bug#33546: Slowdown on re-evaluation of constant expressions. · 987e1466
      Evgeny Potemkin authored
            
      Constant expressions in WHERE/HAVING/ON clauses aren't cached and evaluated
      for each row. This causes slowdown of query execution especially if constant
      UDF/SP function are used.
            
      Now WHERE/HAVING/ON expressions are analyzed in the top-bottom direction with
      help of the compile function. When analyzer meets a constant item it
      sets a flag for the tree transformer to cache the item and doesn't allow tree
      walker to go deeper. Thus, the topmost item of a constant expression if
      cached. This is done after all other optimizations were applied to
      WHERE/HAVING/ON expressions
            
      A helper function called cache_const_exprs is added to the JOIN class.
      It calls compile method with caching analyzer and transformer on WHERE,
      HAVING, ON expressions if they're present.
      The cache_const_expr_analyzer and cache_const_expr_transformer functions are
      added to the Item class. The first one check if the item can be cached and
      the second caches it if so.
      A new Item_cache_datetime class is derived from the Item_cache class.
      It caches both int and string values of the underlying item independently to
      avoid DATETIME aware int-to-string conversion. Thus it completely relies on
      the ability of the underlying item to correctly convert DATETIME value from
      int to string and vice versa.
      
      
      mysql-test/r/func_like.result:
        A test case result is corrected after fixing bug#33546.
      mysql-test/r/func_time.result:
        A test case result is corrected after fixing bug#33546.
      mysql-test/r/select.result:
        Added a test case for the bug#33546.
      mysql-test/r/subselect.result:
        A test case result is corrected after fixing bug#33546.
      mysql-test/r/udf.result:
        Added a test case for the bug#33546.
      mysql-test/t/select.test:
        Added a test case for the bug#33546.
      mysql-test/t/udf.test:
        Added a test case for the bug#33546.
      sql/item.cc:
        Bug#33546: Slowdown on re-evaluation of constant expressions.
        The cache_const_expr_analyzer and cache_const_expr_transformer functions are
        added to the Item class. The first one check if the item can be cached and
        the second caches it if so.
        Item_cache_datetime class implementation is added.
      sql/item.h:
        Bug#33546: Slowdown on re-evaluation of constant expressions.
        Item_ref and Item_cache classes now returns basic_const_item
        from underlying item.
        The cache_const_expr_analyzer and cache_const_expr_transformer functions are
        added to the Item class.
      sql/sql_select.cc:
        Bug#33546: Slowdown on re-evaluation of constant expressions.
                
        A helper function called cache_const_exprs is added to the JOIN class.
        It calls compile method with caching analyzer and transformer on WHERE,
        HAVING, ON expressions if they're present.
      sql/sql_select.h:
        Bug#33546: Slowdown on re-evaluation of constant expressions.
        A helper function called cache_const_exprs is added to the JOIN class.
      987e1466
  31. 25 Nov, 2009 2 commits
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · 6aeeacb8
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 1810.3961.7
      > committer: Georgi Kodinov <joro@sun.com>
      > branch nick: B48291-5.0-bugteam
      > timestamp: Fri 2009-10-30 15:15:43 +0200
      > message:
      >   Bug #48291 : crash with row() operator,select into @var, and
      >     subquery returning multiple rows
      >
      >   Error handling was missing when handling subqueires in WHERE
      >   and when assigning a SELECT result to a @variable.
      >   This caused crash(es).
      >
      >   Fixed by adding error handling code to both the WHERE
      >   condition evaluation and to assignment to an @variable.
      > ------------------------------------------------------------
      6aeeacb8
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · df570b7c
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 1810.3959.4
      > revision-id: ramil@mysql.com-20091021090408-208mvwwrcroi2j8c
      > parent: azundris@mysql.com-20091021033856-ydodp4q42o58e7ka
      > committer: Ramil Kalimullin <ramil@mysql.com>
      > branch nick: b47019-5.0-bugteam
      > timestamp: Wed 2009-10-21 14:04:08 +0500
      > message:
      >   Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
      >   line 138 when forcing a spatial index
      >   
      >   Problem: "Spatial indexes can be involved in the search 
      >   for queries that use a function such as MBRContains() 
      >   or MBRWithin() in the WHERE clause".
      >   Using spatial indexes for JOINs with =, <=> etc.
      >   predicates is incorrect.
      >   
      >   Fix: disable spatial indexes for such queries.
      df570b7c
  32. 13 Nov, 2009 1 commit
    • Jorgen Loland's avatar
      Bug#48052: Valgrind warning - uninitialized value in · a120e969
      Jorgen Loland authored
                 init_read_record() - (records.cc:274)
            
      Item_cond::used_tables_cache was accessed in
      records.cc#init_read_record() without being initialized. It had
      not been initialized because it was wrongly assumed that the
      Item's variables would not be accessed, and hence
      quick_fix_field() was used instead of fix_fields() to save a few
      CPU cycles at creation time.
      
      The fix is to properly initilize the Item by replacing
      quick_fix_field() with fix_fields().
      
      
      mysql-test/r/select.result:
        Add test for BUG#48052
      mysql-test/t/select.test:
        Add test for BUG#48052
      sql/sql_select.cc:
        Properly initialize Item_cond_and by calling fix_fields (instead of quick_fix_field) when the Item that "ANDs" WHERE clause conditions with HAVING clause conditions is created.
      a120e969
  33. 09 Nov, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #48458: simple query tries to allocate enormous amount of · 4519d5e4
      Georgi Kodinov authored
        memory
      
      The server was doing a bad class typecast causing setting of 
      wrong value for the maximum number of items in an internal
      structure used in equality propagation.
      Fixed by not doing the wrong typecast and asserting the type
      of the Item where it should be done.
      4519d5e4
  34. 30 Oct, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #48291 : crash with row() operator,select into @var, and · 9d96cd6d
      Georgi Kodinov authored
        subquery returning multiple rows
      
      Error handling was missing when handling subqueires in WHERE 
      and when assigning a SELECT result to a @variable.
      This caused crash(es). 
      
      Fixed by adding error handling code to both the WHERE 
      condition evaluation and to assignment to an @variable.
      9d96cd6d
  35. 21 Oct, 2009 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, · 17ed6b9a
      Ramil Kalimullin authored
      line 138 when forcing a spatial index
      
      Problem: "Spatial indexes can be involved in the search 
      for queries that use a function such as MBRContains() 
      or MBRWithin() in the WHERE clause".
      Using spatial indexes for JOINs with =, <=> etc.
      predicates is incorrect.
      
      Fix: disable spatial indexes for such queries.
      
      
      mysql-test/r/select.result:
        Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
        line 138 when forcing a spatial index
          - test result.
      mysql-test/t/select.test:
        Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
        line 138 when forcing a spatial index
          - test case.
      sql/sql_select.cc:
        Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
        line 138 when forcing a spatial index
          - disable spatial indexes for queries which use 
        non-spatial conditions (e.g. NATURAL JOINs).
      17ed6b9a