An error occurred fetching the project authors.
- 08 Oct, 2013 1 commit
-
-
Sergey Petrunya authored
- if EXPLAIN DELETE prints "Deleting all rows", it should show the expected number of rows in the rows column.
-
- 07 Oct, 2013 1 commit
-
-
Sergey Petrunya authored
- Add support for EXPLAIN INSERT.
-
- 05 Oct, 2013 2 commits
-
-
Sergey Petrunya authored
- Address review feedback: rename files
-
Sergey Petrunya authored
- Address review feedback: rename nearly any name used by the new EXPLAIN code.
-
- 04 Oct, 2013 1 commit
-
-
Sergey Petrunya authored
- Make EXPLAIN {PARTITIONS,EXTENDED} {UPDATE,DELETE} work.
-
- 04 Sep, 2013 1 commit
-
-
Sergey Petrunya authored
-
- 16 Jul, 2013 1 commit
-
-
Sergey Petrunya authored
mdev-4173: Wrong result (extra row) with semijoin=on, joins in outer query, LEFT JOIN in the subquery Apply the patch from Patryk Pomykalski: - create_internal_tmp_table_from_heap() will now return information whether the last row that we tried to write was a duplicate row. (mysql-5.6 also has this change)
-
- 15 Jul, 2013 1 commit
-
-
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
-
- 27 Jun, 2013 1 commit
-
-
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.
-
- 20 Jun, 2013 1 commit
-
-
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)
-
- 17 Jun, 2013 1 commit
-
-
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.
-
- 05 Jun, 2013 1 commit
-
-
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()
-
- 18 Apr, 2013 1 commit
-
-
unknown authored
Sampling of selectivity of LIKE predicate.
-
- 16 Apr, 2013 1 commit
-
-
Igor Babaev authored
Renamed the virtual method middle_point_pos for the class Field to pos_in_interval.
-
- 20 Mar, 2013 1 commit
-
-
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.
-
- 19 Mar, 2013 1 commit
-
-
Murthy Narkedimilli authored
-
- 11 Mar, 2013 1 commit
-
-
Igor Babaev authored
-
- 12 Feb, 2013 1 commit
-
-
Sergey Petrunya authored
- Backported the code to 10.0-base - Removed incorrect assert
-
- 08 Feb, 2013 1 commit
-
-
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.
-
- 15 Jan, 2013 1 commit
-
-
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.
-
- 14 Jan, 2013 1 commit
-
-
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.
-
- 26 Nov, 2012 1 commit
-
-
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.
-
- 04 Nov, 2012 1 commit
-
-
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.
-
- 26 Oct, 2012 1 commit
-
-
unknown authored
This patch undoes the removal of enum store_key_result by the previous patch for mdev-3812.
-
- 25 Oct, 2012 1 commit
-
-
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.
-
- 31 Aug, 2012 1 commit
-
-
Sergei Golubchik authored
MDEV-414 Depending on indexes or execution plans, a warning on incorrect or out of range values in WHERE condition is sometimes produced and sometimes not use the same method that disables warnings in all relevant places, remove redundant function
-
- 21 Aug, 2012 1 commit
-
-
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.
-
- 19 Jul, 2012 1 commit
-
-
Sergey Petrunya authored
-
- 04 Jun, 2012 1 commit
-
-
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().
-
- 17 May, 2012 1 commit
-
-
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.
-
- 11 May, 2012 1 commit
-
-
Sergey Petrunya authored
- Fix the bug: SHOW EXPLAIN may hit a case where a join is partially optimized. - Change JOIN::optimized to use enum instead of numeric constants
-
- 10 May, 2012 2 commits
-
-
Sergey Petrunya authored
- Make all functions that produce parts of EXPLAIN output take explain_flags as parameter, instead of looking into thd->lex->describe
-
Sergey Petrunya authored
- Support SHOW EXPLAIN for selects that have "Using temporary; Using filesort".
-
- 08 May, 2012 2 commits
- 27 Apr, 2012 1 commit
-
-
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.
-
- 23 Apr, 2012 1 commit
-
-
Sergei Golubchik authored
install all private headers in mysql/private/
-
- 23 Mar, 2012 1 commit
-
-
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
-
- 03 Feb, 2012 1 commit
-
-
Vladislav Vaintroub authored
Also, restrict symbol visibility in statically built plugins, to minimize the chance for symbol name clashes with dynamic plugins.
-
- 25 Jan, 2012 1 commit
-
-
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.
-