An error occurred fetching the project authors.
  1. 08 Oct, 2013 1 commit
  2. 07 Oct, 2013 1 commit
  3. 05 Oct, 2013 2 commits
  4. 04 Oct, 2013 1 commit
  5. 04 Sep, 2013 1 commit
  6. 16 Jul, 2013 1 commit
  7. 15 Jul, 2013 1 commit
    • Sergey Petrunya's avatar
      MDEV-4536, MDEV-4042 · 716a49a1
      Sergey Petrunya authored
      - Make JOIN::cleanup(true) also work correctly when the query is KILLed
        after join optimization was started but before a query plan was produced
      716a49a1
  8. 27 Jun, 2013 1 commit
    • Sergey Petrunya's avatar
      [SHOW] EXPLAIN UPDATE/DELETE, code re-structuring · 8b7bbcf4
      Sergey Petrunya authored
      - Make query plan be re-saved after the first join execution
        (saving it after JOIN::cleanup is too late because EXPLAIN output 
         is currently produced before that)
      - Handle QPF allocation/deallocation for edge cases, like unsuccessful
        BINLOG command.
      - Work around the problem with UNION's direct subselects not being visible.
      - Update test results ("Using temporary; Using filesort" are now always printed 
        last in the Extra column)
      - This cset gets rid of memory leaks/crashes. Some result mismatches still remain.
      8b7bbcf4
  9. 20 Jun, 2013 1 commit
    • Sergey Petrunya's avatar
      Switching [EXPLAIN] UPDATE/DELETE to rely on query plan footprints. · ab4a13b2
      Sergey Petrunya authored
      This requires that subselect's footprints are saved before it is deleted.
      
      Attempt to save select's QPF exposes one to a variety of edge cases:
      - the select may be a UNION's "fake select" which has no valid id
      - optimization may fail in the middle (but subsequent JOIN::optimize() calls
        will succeed, despite the fact that there never was a query plan)
      ab4a13b2
  10. 17 Jun, 2013 1 commit
    • Sergey Petrunya's avatar
      SHOW EXPLAIN UPDATE/DELETE · 03691a77
      Sergey Petrunya authored
      - Introduce "Query Plan Footprints" (abbrev. QPFs)
        QPF is a part of query plan that is 
        1. sufficient to produce EXPLAIN output,
        2. can be used to produce EXPLAIN output even after its subquery/union
           was executed and deleted
        3. is cheap to save so that we can always save query plans
      
      - This patch doesn't fully address #2, we make/save strings for 
        a number of EXPLAIN's columns.  This will be fixed.
      
      03691a77
  11. 05 Jun, 2013 1 commit
    • Michael Widenius's avatar
      -Run test suite with smaller aria keybuffer size (to make it possible to run... · bef95a4b
      Michael Widenius authored
      -Run test suite with smaller aria keybuffer size (to make it possible to run more tests in parallel)
      -Added test and extra code to ensure we don't leave keyread on for a handler table.
      -Create on disk temporary files always with long data pointers if SQL_SMALL_RESULT is not used. This ensures that we can handle temporary files bigger than 4G.
      
      mysql-test/include/default_mysqld.cnf:
        Run test suite with smaller aria keybuffer size
      mysql-test/suite/maria/maria3.result:
        Run test suite with smaller aria keybuffer size
      mysql-test/suite/sys_vars/r/aria_pagecache_buffer_size_basic.result:
        Run test suite with smaller aria keybuffer size
      sql/handler.cc:
        Disable key read (extra safety if something went wrong)
      sql/multi_range_read.cc:
        Ensure we have don't leave keyread on for secondary_file
      sql/opt_range.cc:
        Simplify code with mark_columns_used_by_index_no_reset()
        Ensure that read_keys_and_merge() disableds keyread if it enables it
      sql/opt_subselect.cc:
        Remove not anymore used argument for create_internal_tmp_table()
      sql/sql_derived.cc:
        Remove not anymore used argument for create_internal_tmp_table()
      sql/sql_select.cc:
        Use 'enable_keyread()' instead of calling HA_EXTRA_RESET. (Makes debugging easier)
        Create on disk temporary files always with long data pointers if SQL_SMALL_RESULT is not used. This ensures that we can handle temporary files bigger than 4G.
        Remove not anymore used argument for create_internal_tmp_table()
        More DBUG
      sql/sql_select.h:
        Remove not anymore used argument for create_internal_tmp_table()
      bef95a4b
  12. 18 Apr, 2013 1 commit
    • unknown's avatar
      MDEV-4345 · 9441e536
      unknown authored
      Sampling of selectivity of LIKE predicate.
      9441e536
  13. 16 Apr, 2013 1 commit
    • Igor Babaev's avatar
      Added comments. · b12b3cae
      Igor Babaev authored
      Renamed the virtual method middle_point_pos for the class Field to
      pos_in_interval.
      b12b3cae
  14. 20 Mar, 2013 1 commit
    • Jorgen Loland's avatar
      Bug#16394084: LOOSE INDEX SCAN WITH QUOTED INT PREDICATE · 30e2a543
      Jorgen Loland authored
                    RETURNS RANDOM DATA
                       
      MySQL 5.5 specific version of bugfix.
            
      When Loose Index Scan Range access is used, MySQL execution needs
      to copy non-aggregated fields. end_send() checked if this was
      necessary by checking if join_tab->select->quick had type
      QS_TYPE_GROUP_MIN_MAX.
            
      In this bug, however, MySQL created a sort index to sort the rows
      read from this range access method. create_sort_index() deletes
      join_tab->select->quick which makes it impossible to inquire
      the join_tab if LIS has been used.
            
      The fix for MySQL 5.5 is to introduce a variable in JOIN_TAB
      that stores whether or not LIS has been used. There is no need
      for this variable in later MySQL versions because the relevant
      code has been refactored.
      30e2a543
  15. 19 Mar, 2013 1 commit
  16. 11 Mar, 2013 1 commit
  17. 12 Feb, 2013 1 commit
  18. 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
  19. 15 Jan, 2013 1 commit
    • Olav Sandstaa's avatar
      Fix for Bug#14636211 WRONG RESULT (EXTRA ROW) ON A FROM SUBQUERY · e7ad5e36
      Olav Sandstaa authored
                           WITH A VARIABLE AND ORDER BY
              Bug#16035412 MYSQL SERVER 5.5.29 WRONG SORTING USING COMPLEX INDEX
                  
      This is a fix for a regression introduced by Bug#12667154:
      Bug#12667154 attempted to fix a performance problem with subqueries
      that did filesort. For doing filesort, the optimizer creates a quick
      select object to use when building the sort index. This quick select
      object was deleted after the first call to create_sort_index(). Thus,
      for queries where the subquery was executed multiple times, the quick
      object was only used for the first execution. For all later executions
      of the subquery, filesort used a complete table scan for building the
      sort index. The fix for Bug#12667154 tried to fix this by not deleting
      the quick object after the first execution of create_sort_index() so
      that it would be re-used for building the sort index by the following
      executions of the subquery.
      
      This regression introduced in Bug#12667154 is that due to not deleting
      the quick select object after building the sort index, the quick
      object could in some cases be used also during the second phase of the
      execution of the subquery instead of using the created sort
      index. This caused wrong results to be returned.
      
      The fix for this issue is to delete the reference to the select object
      after it has been used in create_sort_index(). In this way the select 
      and quick objects will not be available when doing the second phase
      of the execution of the select operation. To ensure that the select
      object can be re-used for the following executions of the subquery
      we make a copy of the select pointer. This is used for restoring the
      select object after the select operation is completed.
      
      
      mysql-test/suite/innodb/r/innodb_mysql.result:
        Changed explain output: The explain now contains "Using where" since we
        have restored the select pointer after doing the filesort operation.
      sql/sql_select.cc:
        Change create_sort_index() so that it always sets the pointer to
        the select object to NULL. This is done in order to avoid that the
        select->quick object can be used when execution the main part of
        the select operation.
      sql/sql_select.h:
        New member in JOIN_TAB: saved_select. Used by create_sort_index to
        make a backup copy of the select pointer.
      e7ad5e36
  20. 14 Jan, 2013 1 commit
    • Olav Sandstaa's avatar
      Fix for Bug#14636211 WRONG RESULT (EXTRA ROW) ON A FROM SUBQUERY · fd5380b4
      Olav Sandstaa authored
                           WITH A VARIABLE AND ORDER BY
              Bug#16035412 MYSQL SERVER 5.5.29 WRONG SORTING USING COMPLEX INDEX
            
      This is a fix for a regression introduced by Bug#12667154:
      Bug#12667154 attempted to fix a performance problem with subqueries
      that did filesort. For doing filesort, the optimizer creates a quick
      select object to use when building the sort index. This quick select
      object was deleted after the first call to create_sort_index(). Thus,
      for queries where the subquery was executed multiple times, the quick
      object was only used for the first execution. For all later executions
      of the subquery, filesort used a complete table scan for building the
      sort index. The fix for Bug#12667154 tried to fix this by not deleting
      the quick object after the first execution of create_sort_index() so
      that it would be re-used for building the sort index by the following
      executions of the subquery.
            
      This regression introduced in Bug#12667154 is that due to not deleting
      the quick select object after building the sort index, the quick
      object could in some cases be used also during the second phase of the
      execution of the subquery instead of using the created sort
      index. This caused wrong results to be returned.
            
      The fix for this issue is to delete the reference to the select object
      after it has been used in create_sort_index(). In this way the select 
      and quick objects will not be available when doing the second phase
      of the execution of the select operation. To ensure that the select
      object can be re-used for the following executions of the subquery
      we make a copy of the select pointer. This is used for restoring the
      select object after the select operation is completed.
      
      
      mysql-test/suite/innodb/r/innodb_mysql.result:
        Changed explain output: The explain now contains "Using where" since we
        have restored the select pointer after doing the filesort operation.
      sql/sql_select.cc:
        Change create_sort_index() so that it always sets the pointer to
        the select object to NULL. This is done in order to avoid that the
        select->quick object can be used when execution the main part of
        the select operation.
      sql/sql_select.h:
        New member in JOIN_TAB: saved_select. Used by create_sort_index to
        make a backup copy of the select pointer.
      fd5380b4
  21. 26 Nov, 2012 1 commit
    • unknown's avatar
      Fix of MDEV-3874: Server crashes in Item_field::print on a SELECT from a MERGE... · b8b875cb
      unknown authored
      Fix of MDEV-3874: Server crashes in Item_field::print on a SELECT from a MERGE view with materialization+semijoin, subquery, ORDER BY.
      
      The problem was that in debugging binaries it try to print item to assign human readable name to the item.
      But subquery item was already freed (join_free/cleanup with full cleanup) so Item_field refers to temporary
      table which memory had been already freed.
      b8b875cb
  22. 04 Nov, 2012 1 commit
    • Sergey Petrunya's avatar
      MDEV-536: LP:1050806 - different result for a query using subquery, and · 39e7072d
      Sergey Petrunya authored
      MDEV-567: Wrong result from a query with correlated subquery if ICP is allowed:
      
      backport the fix developed for SHOW EXPLAIN: 
      
      revision-id: psergey@askmonty.org-20120719115219-212cxmm6qvf0wlrb
      branch nick: 5.5-show-explain-r21
      timestamp: Thu 2012-07-19 15:52:19 +0400
        BUG#992942 & MDEV-325: Pre-liminary commit for testing
      
      and adjust it so that it handles DS-MRR scans correctly.
      39e7072d
  23. 26 Oct, 2012 1 commit
    • unknown's avatar
      MDEV-3812 · 974abc7a
      unknown authored
      This patch undoes the removal of enum store_key_result by the previous patch for mdev-3812.
      974abc7a
  24. 25 Oct, 2012 1 commit
    • unknown's avatar
      MDEV-3812: Remove unneeded extra call to engine->exec() in... · 97a1c53c
      unknown authored
      MDEV-3812: Remove unneeded extra call to engine->exec() in Item_subselect::exec, remove enum store_key_result
      
      This task fixes an ineffeciency that is a remainder from MySQL 5.0/5.1. There, subqueries
      were optimized in a lazy manner, when executed for the first time. During this lazy optimization
      it may happen that the server finds a more efficient subquery engine, and substitute the current
      engine of the query being executed with the new engine. This required re-execution of the engine.
      
      MariaDB 5.3 pre-optimizes subqueries in almost all cases, and the engine is chosen in most cases,
      except when subquery materialization found that it must use partial matching. In this case, the
      current code was performing one extra re-execution although it was not needed at all. The patch
      performs the re-execution only if the engine was changed while executing.
      
      In addition the patch performs small cleanup by removing "enum store_key_result" because it is
      essentially a boolean, and the code that uses it already maps it to a boolean.
      97a1c53c
  25. 31 Aug, 2012 1 commit
  26. 21 Aug, 2012 1 commit
    • unknown's avatar
      Fix bug mdev-447: Wrong output from the EXPLAIN command of the test case for lp bug #714999 · 80b3f747
      unknown authored
      The fix backports from MWL#182: Explain running statements the logic that
      saves the original JOIN_TAB array of a query plan after optimization. This
      array is later used during EXPLAIN to iterate over the original JOIN plan
      nodes in the cases when this plan could be changed by early subquery
      execution during the optimization phase of the outer query.
      80b3f747
  27. 19 Jul, 2012 1 commit
  28. 04 Jun, 2012 1 commit
    • Sergey Petrunya's avatar
      MDEV-305: SHOW EXPLAIN: ref returned by SHOW EXPLAIN is different from the... · a8b2e831
      Sergey Petrunya authored
      MDEV-305: SHOW EXPLAIN: ref returned by SHOW EXPLAIN is different from the normal EXPLAIN ('const' vs empty string)
      - The problem was that create_ref_for_key() would act differently, depending on 
        whether we're running EXPLAIN or the actual query.
      - As the first step, fixed the EXPLAIN printout not to depend on actions in create_ref_for_key().
      a8b2e831
  29. 17 May, 2012 1 commit
    • 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
  30. 11 May, 2012 1 commit
  31. 10 May, 2012 2 commits
  32. 08 May, 2012 2 commits
  33. 27 Apr, 2012 1 commit
    • unknown's avatar
      Fix bug lp:985667, MDEV-229 · c04786d3
      unknown authored
      Analysis:
      
      The reason for the wrong result is the interaction between constant
      optimization (in this case 1-row table) and subquery optimization.
      
      - First the outer query is optimized, and 'make_join_statistics' finds that
      table t2 has one row, reads that row, and marks the whole table as constant.
      This also means that all fields of t2 are constant.
      
      - Next, we optimize the subquery in the end of the outer 'make_join_statistics'.
      The field 'f2' is considered constant, with value '3'. The subquery predicate
      is rewritten as the constant TRUE.
      
      - The outer query execution detects early that the whole query result is empty
      and calls 'return_zero_rows'. Since the query is with implicit grouping, we
      have to produce one row with special values for the aggregates (depending on
      each aggregate function), and NULL values for all non-aggregate fields.  This
      function calls 'no_rows_in_result' to set each aggregate function to the
      default value when it aggregates over an empty result, and then calls
      'send_data', which in turn evaluates each Item in the SELECT list.
      
      - When evaluation reaches the subquery predicate, it executes the subquery
      with field 'f2' having a constant value '3', and the subquery produces the
      incorrect result '7'.
      
      Solution:
      
      Implement Item::no_rows_in_result for all subquery predicates. In order to
      make this work, it is also needed to make all val_* methods of all subquery
      predicates respect the Item_subselect::forced_const flag. Otherwise subqueries
      are executed anyways, and override the default value set by no_rows_in_result
      with whatever result is produced from the subquery evaluation.
      c04786d3
  34. 23 Apr, 2012 1 commit
  35. 23 Mar, 2012 1 commit
    • Michael Widenius's avatar
      Fixes lp:941889 "JOIN constructors takes a long time in 5.3" · 8e825a22
      Michael Widenius authored
      - Remove all references of MAX_TABLES from JOIN struct and make these dynamic
      - Updated Join_plan_state to allocate just as many elements as it's needed
      
      
      sql/opt_subselect.cc:
        Optimized version of Join_plan_state
      sql/sql_select.cc:
        Set join->positions and join->best_positions dynamicly
        Don't call update_virtual_fields() if table->vfield is not set.
      sql/sql_select.h:
        Remove all references of MAX_TABLES from JOIN struct and Join_plan_state and make these dynamic
      8e825a22
  36. 03 Feb, 2012 1 commit
  37. 25 Jan, 2012 1 commit
    • Sergey Petrunya's avatar
      BUG#920713: Wrong result (missing rows) with firstmatch+BNL, IN subquery, ... · 424f56b3
      Sergey Petrunya authored
      - Disable use of join cache when we're using FirstMatch strategy, and the join
        order is such that subquery's inner tables are interleaved with outer.  Join 
        buffering code is incapable of handling such join orders.
      
      - The testcase requires use of @@debug_optimizer_prefer_join_prefix to hit the bug, 
        but I'm pushing it anyway (including the mention of the variable in .test file), 
        so that it can be found and enabled when/if we get something comparable in the 
        main tree.
      424f56b3