mariadb

Tree: d34e46795e

Author	SHA1	Message	Date
Igor Babaev	c0f31dc9f3	Another attempt to fix bug mdev-5103. The earlier pushed fix for the bug was incomplete. It did not remove the main cause of the problem: the function remove_eq_conds() removed always true multiple equalities from any conjunct, but did not adjust the list of them stored in Item_cond_and::cond_equal.current_level. Simplified the test case for the bug and moved it to another test file. The fix triggered changes in EXPLAIN EXTENDED for some queries.	12 years ago
Igor Babaev	37f18d2318	Fixed bug mdev-4962. When a non-nullable datetime field is used under an IS NULL predicate of the WHERE condition in a query with outer joins the remove_eq_conds function should check whether this field belongs to an inner table of any outer join that can be, in a general case, a nested outer join.	12 years ago
Sergey Petrunya	d6f7649d3c	mdev-4942: Add another testcase after merging with other fixes.	12 years ago
Igor Babaev	650d3266bb	Fixed bug mdev-4952 When in function remove_eq_conds() a sub-formula of the processed condition is replaced for another formula we should ensure that in the resulting formula AND/OR levels must alternate.	12 years ago
Igor Babaev	901737c978	Fixed bug mdev-4944. 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.	12 years ago
Sergey Petrunya	edd980225a	Fix for MDEV-4836 fix: take into account situation where "notnull_col IS NULL" is not a direct child of the WHERE clause item, but rather is embedded inside Item_cond_and or Item_cond_or.	12 years ago
Igor Babaev	dbc84ff96c	Fixed bug mdev-4942. Made sure that degenerate conjunctions/disjunctions are obtained from AND/OR conditions.	12 years ago
Sergey Petrunya	970542ec90	MDEV-4836: Wrong result on <not null date column> IS NULL (old documented hack stopped working) - When applying optimization introduced by MDEV-4817, ignore the conditions that have form "datetime_not_null_col IS NULL".	12 years ago
Igor Babaev	25c152018d	Fixed bug mdev-4418. 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().	12 years ago
Sergey Petrunya	04684b7709	MDEV-4817: Optimizer fails to optimize expression of the form 'FOO' IS NULL - Modify the way Item_cond::fix_fields() and Item_cond::eval_not_null_tables() calculate bitmap for Item_cond_or::not_null_tables(): if they see a "... OR inexpensive_const_false_item OR ..." then the item can be ignored. - Updated test results. There can be more warnings produced since parts of WHERE are evaluated more times.	12 years ago
Igor Babaev	920c479c6e	Fixed bug mdev-4336. When iterating over a list of conditions using List_iterator the function remove_eq_conds should skip all predicates that replace a condition from the list. Otherwise it can come to an infinite recursion.	13 years ago
Igor Babaev	d434d79acf	Fixed bug mdev-4177 The function remove_eq_cond removes the parts of a disjunction for which it has been proved that they are always true. In the result of this removal the disjunction may be converted into a formula without OR that must be merged into the the AND formula that contains the disjunction. The merging of two AND conditions must take into account the multiple equalities that may be part of each of them. These multiple equality must be merged and become part of the and object built as the result of the merge of the AND conditions. Erroneously the function remove_eq_cond lacked the code that would merge multiple equalities of the merged AND conditions. This could lead to confusing situations when at the same AND level there were two multiple equalities with common members and the list of equal items contained only some of these multiple equalities. This, in its turn, could lead to an incorrect work of the function substitute_for_best_equal_field when it tried to optimize ref accesses. This resulted in forming invalid TABLE_REF objects that were used to build look-up keys when materialized subqueries were exploited.	13 years ago
Michael Widenius	c65f9a1914	Don't reset maybe_null in update_used_tables(); This breaks ROLLUP This fixed failing test in group_by.test mysql-test/r/join_outer.result: Updated test case mysql-test/r/join_outer_jcl6.result: Updated test case sql/item.cc: Don't reset maybe_null in update_used_tables(); This breaks ROLLUP sql/item.h: Don't reset maybe_null in update_used_tables(); This breaks ROLLUP sql/item_cmpfunc.h: Don't reset maybe_null in update_used_tables(); This breaks ROLLUP	13 years ago
unknown	8a296e6ca2	backport of: Don't reset maybe_null in update_used_tables(); This breaks ROLLUP This fixed failing test in group_by.test	13 years ago
unknown	6f26aac940	MDEV-3873 & MDEV-3876 & MDEV-3912 : Wrong result (extra rows) with ALL subquery from a MERGE view. The problem was in the lost ability to be null for the table of a left join if it is a view/derived table. It hapenned because setup_table_map(), was called earlier then we merged the view or derived. Fixed by propagating new maybe_null flag during Item::update_used_tables(). Change in join_outer.test and join_outer_jcl6.test appeared because IS NULL reported no used tables (i.e. constant) for argument which could not be NULL and new maybe_null flag was propagated for IS NULL argument (Item_field) because table the Item_field belonged to changed its maybe_null status.	13 years ago
unknown	f1ab00891a	Fixed bug lp:1000649 Analysis: When the method JOIN::choose_subquery_plan() decided to apply the IN-TO-EXISTS strategy, it set the unit and select_lex uncacheable flag to UNCACHEABLE_DEPENDENT_INJECTED unconditionally. As result, even if IN-TO-EXISTS injected non-correlated predicates, the subquery was still treated as correlated. Solution: Set the subquery as correlated only if the injected predicate(s) depend on the outer query.	14 years ago
unknown	941018f8d1	Patch for mdev-287: CHEAP SQ: A query with subquery in SELECT list, EXISTS, inner joins takes hundreds times longer Analysis: The fix for lp:944706 introduces early subquery optimization. While a subquery is being optimized some of its predicates may be removed. In the test case, the EXISTS subquery is constant, and is evaluated to TRUE. As a result the whole OR is TRUE, and thus the correlated condition "b = alias1.b" is optimized away. The subquery becomes non-correlated. The subquery cache is designed to work only for correlated subqueries. If constant subquery optimization is disallowed, then the constant subquery is not evaluated, the subquery remains correlated, and its execution is cached. As a result execution is fast. However, when the constant subquery was optimized away, it was neither cached by the subquery cache, nor it was cached by the internal subquery caching. The latter was due to the fact that the subquery still appeared as correlated to the subselect_XYZ_engine::exec methods, and they re-executed the subquery on each call to Item_subselect::exec. Solution: The solution is to update the correlated status of the subquery after it has been optimized. This status consists of: - st_select_lex::is_correlated - Item_subselect::is_correlated - SELECT_LEX::uncacheable - SELECT_LEX_UNIT::uncacheable The status is updated by st_select_lex::update_correlated_cache(), and its caller st_select_lex::optimize_unflattened_subqueries. The solution relies on the fact that the optimizer already called st_select_lex::update_used_tables() for each subquery. This allows to efficiently update the correlated status of each subquery without walking the whole subquery tree. Notice that his patch is an improvement over MySQL 5.6 and older, where subqueries are not pre-optimized, and the above analysis is not possible.	14 years ago
unknown	da5214831d	Fix for bug lp:944706, task MDEV-193 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.	14 years ago
Igor Babaev	000deedf3b	Fixed LP bug #943543 . This bug appeared after the patch for bug 939009 that in the function merge_key_fields forgot to reset a proper value for the val field in the result of the merge operation of the key field created for a regular key access and the key field created to look for a NULL key. Adjusted the results of the test case for bug 939009 that actually were incorrect.	14 years ago
Michael Widenius	5438d57315	Added Handler_read_rnd_deleted, number of deleted rows found with ha_read_rnd_first.	14 years ago
Igor Babaev	a910e8ef5b	Made join_cache_level == 2 by default.	14 years ago
Igor Babaev	f5dac20f38	Made the optimizer switch flags 'outer_join_with_cache', 'semijoin_with_cache' set to 'on' by default.	14 years ago
unknown	54caeee5d6	Making subquery cache on by default.	14 years ago
Igor Babaev	715dc5f99d	Fixed a cost estimation bug introduced into in the function best_access_path of the 5.3 code line after a merge with 5.2 on 2010-10-28 in order not to allow the cost to access a joined table to be equal to 0 ever. Expanded data sets for many test cases to get the same execution plans as before.	14 years ago
Igor Babaev	da59130ec1	Fixed LP bug #838633 . For any query JOIN::optimize() should call the method SELECT::save_leaf_tables after the last transformation that utilizes the statement memory rather than the execution memory.	14 years ago
Igor Babaev	249a10c7dd	Fixed LP bug #825035 . The value of maybe_null flag should be saved for the second execution of a prepared statement from SELECT that uses an outer join.	14 years ago
unknown	a6037394e3	Fix bug lp:817384 This bug is a special case of lp:813447. Analysis: Constant optimization finds that the condition t2.a = 1 can be used to access the primary key of table 't2'. As a result both outer table t1,t2 are considered as constant when we reach the execution phase. At the same time, during constant optimization, the IN predicate is not evaluated because it is expensive. When execution of the outer query reaches do_select(), control flow enter the branch: if (join->table_count == join->const_tables) { ... } This branch checks only the WHERE and HAVING clauses, but doesn't check the ON clauses of the query. Since the IN predicate was not evaluated during optimization, it is not evaluated at all, thus execution doesn't detect that the ON clause is FALSE. Solution: Similar to the patch for bug lp:813447, exclude system tables from constant substitution based on unique key lookups if there is an expensive ON condition on the inner table.	14 years ago
Igor Babaev	4a03a1d777	Fixed LP bug #813447 . Do not make substitution of a single-row table if it is an inner table of an outer join with on expression containing an expensive subquery.	14 years ago
unknown	af284b55f0	Make subquery cache off by default. mysql-test/r/subselect_scache.result: Test with subquery cache on. mysql-test/t/subselect_scache.test: Test with subquery cache on.	15 years ago
Igor Babaev	03081bc1fd	Changed the default setting of the optimizer switch 'optimize_join_buffer_size'. Made it 'off' by default.	15 years ago
Sergey Petrunya	1492de8563	Set the default to be mrr=off,mrr_sort_keys=off: - 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	15 years ago
Sergei Golubchik	b4a0b2c2f8	post-merge fixes. most tests pass. 5.3 merge is next	15 years ago
Igor Babaev	20c9084deb	Fixed LP bug #776295 . If the value of the flag cond_false of an Item_equal object is true then the print method must return the string '0'.	15 years ago
Sergei Golubchik	0accbd0364	lots of post-merge changes	15 years ago
Sergey Petrunya	997445bc8e	Make EXPLAIN better at displaying MRR/BKA: - "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.	15 years ago
Igor Babaev	272e5e6212	BNLH algorithm always used a full table scan over the joined table 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.	15 years ago
Igor Babaev	af800fd92f	The patch adds the code that allows to use equi-join conditions for hash join in the cases when there are no suitable indexes for these conditions.	15 years ago
Igor Babaev	25f5debdc7	MWL#128: Added into EXPLAIN output info about types of the used join buffers and about the employed join algorithms. Refactored constructors of the JOIN_CACHE* classes.	15 years ago
Sergey Petrunya	508e75c259	Merge MariaDB 5.2 -> MariaDB 5.3 - post-merge fixes	15 years ago
Igor Babaev	79087c9e07	Ported the fix for bug #57024 (a performance issue for outer joins). Employed the same kind of optimization as in the fix for the cases when join buffer is used. The optimization performs early evaluation of the conditions from on expression with table references to only outer tables of an outer join.	15 years ago
Igor Babaev	21b1b5f040	Fixed bug #52636 . 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.	15 years ago
Sergey Petrunya	3066c37718	DS-MRR improvements: review feedback - Switch from one bi-directional buffer class to two virtual inheritance-based forward and backward buffer classes.	15 years ago
Igor Babaev	94cfcbd9df	The main patch for MWL#128: Implement Block Nested Loop Hash Join.	15 years ago
Sergey Petrunya	8dc81f47ef	Use reverse/backwards buffer for keys (now works) - don't allocate space for rowid buffer when we don't really need it. - fix buffer iterator	15 years ago
Sergey Petrunya	3be133eb4d	Make test result stable (had different result orderings, on some platforms, both of which satisfied the ORDER BY clause).	16 years ago
Igor Babaev	4449a5f489	Backport into MariaDB-5.2 the following: WL#2771 "Block Nested Loop Join and Batched Key Access Join"	16 years ago
Martin Hansson	6863f7dc2d	Bug#47650: using group by with rollup without indexes returns incorrect results with where An outer join of a const table (outer) and a normal table (inner) with GROUP BY on a field from the outer table would optimize away GROUP BY, and thus trigger the optimization to do away with a temporary table if grouping was performed on columns from the const table, hence executing the query with filesort without temporary table. But this should not be done if there is a non-indexed access to the inner table, since filesort does not handle joins. It expects either ref access, range ditto or table scan. The join condition will thus not be applied. Fixed by always forcing execution with temporary table in the case of ROLLUP with a query involving an outer join. This is a slightly broader class of queries than need fixing, but it is hard to ascertain the position of a ROLLUP field wrt outer join with current query representation. mysql-test/r/join_outer.result: Bug#47650: Test result mysql-test/t/join_outer.test: Bug#47650: Test case sql/sql_select.cc: Bug#47650: Fix	16 years ago
Sergey Petrunya	96e092dc73	Backport into MariaDB-5.2 the following: 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.	16 years ago
Marc Alff	63e56390a3	WL#2110 (SIGNAL) WL#2265 (RESIGNAL) Manual merge of SIGNAL and RESIGNAL to mysql-trunk-signal, plus required dependencies.	16 years ago
unknown	90484de3f7	Fixed bug #28571 . Outer join queries with ON conditions over constant outer tables did not return null complemented rows when conditions were evaluated to FALSE. Wrong results were returned because the conditions over constant outer tables, when being pushed down, were erroneously enclosed into the guard function used for WHERE conditions. mysql-test/r/join_outer.result: Added a test case for bug #28571. mysql-test/t/join_outer.test: Added a test case for bug #28571. sql/sql_select.cc: Fixed bug #28571. Outer join queries with ON conditions over constant outer tables did not return null complemented rows when conditions were evaluated to FALSE. Wrong results were returned because the conditions over constant outer tables, when being pushed down, were erroneously enclosed into the guard function used for WHERE conditions. The problem is fixed in the function make_join_select. Now the conditions over constant tables from ON expressions are pushed down after the conditions from WHERE has been pushed down.	19 years ago

1 2

75 Commits (d34e46795ef2691af107b66e04639e10f6b6bdd3)