An error occurred fetching the project authors.
  1. 24 Jan, 2014 1 commit
    • Sergey Petrunya's avatar
      [Backport to 5.3] · 669c6620
      Sergey Petrunya authored
      MDEV-5337: Wrong result in mariadb 5.5.32 with ORDER BY + LIMIT when 
      index_condition_pushdown=on
      - in test_if_skip_sort_order(), correct the condition under which
        we have the code that restores the previously pushed index condition.
      669c6620
  2. 04 Jun, 2012 1 commit
  3. 22 Feb, 2012 1 commit
  4. 16 Feb, 2012 2 commits
    • Sergey Petrunya's avatar
      Backport of: · 541334c5
      Sergey Petrunya authored
      timestamp: Thu 2011-12-01 15:12:10 +0100
      Fix for Bug#13430436 PERFORMANCE DEGRADATION IN SYSBENCH ON INNODB DUE TO ICP
      
      When running sysbench on InnoDB there is a performance degradation due
      to index condition pushdown (ICP). Several of the queries in sysbench
      have a WHERE condition that the optimizer uses for executing these
      queries as range scans. The upper and lower limit of the range scan
      will ensure that the WHERE condition is fulfilled. Still, the WHERE
      condition is part of the queries' condition and if ICP is enabled the
      condition will be pushed down to InnoDB as an index condition. 
      
      Due to the range scan's upper and lower limits ensure that the WHERE
      condition is fulfilled, the pushed index condition will not filter out
      any records. As a result the use of ICP for these queries results in a
      performance overhead for sysbench. This overhead comes from using
      resources for determining the part of the condition that can be pushed
      down to InnoDB and overhead in InnoDB for executing the pushed index
      condition.
      
      With the default configuration for sysbench the range scans will use
      the primary key. This is a clustered index in InnoDB. Using ICP on a
      clustered index provides the lowest performance benefit since the
      entire record is part of the clustered index and in InnoDB it has the
      highest relative overhead for executing the pushed index condition.
      
      The fix for removing the overhead ICP introduces when running sysbench
      is to disable use of ICP when the index used by the query is a
      clustered index.
      
      When WL#6061 is implemented this change should be re-evaluated.
      541334c5
    • unknown's avatar
      607aab9c
  5. 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
  6. 19 Dec, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #904832. · 7a1406f2
      Igor Babaev authored
      Do not perform index condition pushdown for conditions containing subqueries
      and stored functions.
      7a1406f2
  7. 11 Nov, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #879871. · b91a6bd8
      Igor Babaev authored
      The function add_ref_to_table_cond missed updating the value of
      join_tab->pre_idx_push_select_cond after having updated the value
      of join_tab->select->pre_idx_push_select_cond.
      b91a6bd8
  8. 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
  9. 04 Nov, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #885168. · 928e94fb
      Igor Babaev authored
      The call of the virtual function cancel_pushed_idx_cond in the code of
      the function test_if_skip_sort_order was misplaced when backporting the
      fix for bug 58816.
      928e94fb
  10. 01 Nov, 2011 1 commit
  11. 31 Oct, 2011 1 commit
  12. 30 Oct, 2011 4 commits
  13. 29 Oct, 2011 1 commit
  14. 14 Jul, 2011 1 commit
  15. 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
  16. 29 May, 2011 1 commit
  17. 28 May, 2011 2 commits
  18. 27 May, 2011 1 commit
  19. 25 May, 2011 1 commit
  20. 09 Feb, 2011 1 commit
  21. 14 Jan, 2011 2 commits
    • Sergey Petrunya's avatar
      Backport of: · 2d9f6933
      Sergey Petrunya authored
      3150 Olav Sandstaa     2010-05-07
      Test cases for the following "ICP for InnoDB" bugs:
      
      Bug#40992 InnoDB: Crash when engine_condition_pushdown is on
      Bug#35080 Innodb crash at mem_block_get_len line 72
      Bug#41996 multi-table delete crashes server (InnoDB table)
      Bug#43448 Server crashes on multi table delete with Innodb
      
      All these bugs are duplicates of either one or both of Bug 43360 or 36981.
      
      (backporting of olav@sun.com-20100226091930-qxvakxmcp6463t5w)
      2d9f6933
    • Sergey Petrunya's avatar
      Test case backport for: Bug#42580 - Innodb's ORDER BY ..LIMIT returns no rows... · d0535d80
      Sergey Petrunya authored
      Test case backport for: Bug#42580 - Innodb's ORDER BY ..LIMIT returns no rows for null-safe operator <=> NULL
      d0535d80