mariadb

Commit Graph

Author	SHA1	Message	Date
Igor Babaev	5e61e1716e	MDEV-14515 ifnull result depends on number of rows in joined table Any expensive WHERE condition for a table-less query with implicit aggregation was lost. As a result the used aggregate functions were calculated over a non-empty set of rows even in the case when the condition was false.	8 years ago
Varun Gupta	2dd4e50d5f	MDEV-15555: select from DUAL where false yielding wrong result when in a IN For the query having an IN subquery with no tables, we were converting the subquery with an expression between the left part and the select list of the subquery . This can give incorrect results when we have a condition in the subquery with a dual table (as this is treated as a no table). The fix is that we don't do this conversion when we have conds in the subquery with a dual table.	8 years ago
Varun Gupta	adbe1c5fe9	MDEV-6486: Assertion `!table \|\| (!table->read_set \|\| bitmap_is_set(table->read_set, field_index))' failed with SELECT SQ, TEXT field The functon find_all_keys does call Item_subselect::walk, which calls walk() for the subquery The issue is that when a field is represented by Item_outer_ref(Item_direct_ref(Item_copy_string( ...))). Item_copy_string does have a pointer to an Item_field in Item_copy::item but does not implement Item::walk method, so we are not able to set the bitmap for that field. This is the reason why the assert fails. Fixed by adding the walk method to Item_copy class.	9 years ago
Varun Gupta	43903745e5	MDEV-11078: NULL NOT IN (non-empty subquery) should never return results Disabling the cond guards during the creation of Tricond Item for constant and NULL left expression items	9 years ago
Sergei Petrunia	268bb69bea	MDEV-7691: Assertion `outer_context \|\| !from_field \|\| from_field == not_found_field' ... The bug occurred when a subquery - has a reference to outside, to grand-parent query or further up - is converted to a semi-join (i.e. merged into its parent). Then the reference to outside had form Item_ref(Item_field(...)). - Conversion to semi-join would call item->fix_after_pullout() for the outside reference. - Item_ref::fix_after_pullout would call Item_field->fix_after_pullout - The Item_field would construct a new Name_resolution_context object This process ignored the fact that the Item_field does not belong to any of the subselects being flattened. The result was crash in the next call to Item_field::fix_fields(), where we would try to use an invalid Name_resolution_context object. Fixed by not creating Name_resolution_context object if the Item_field's context does not belong to the subselect(s) that were flattened.	9 years ago
Igor Babaev	1f2ef57403	Fixed bug mdev-5686. The calls of the function remove_eq_conds() may change the and/or structure of the where conditions. So JOIN::equal_cond should be updated for non-recursive calls of remove_eq_conds().	12 years ago
Igor Babaev	5b441013e1	Fixed bug mdev-5468. The field JOIN::select_lex->where should be updated after the call of remove_eq_conds() in the function make_join_statistics(). This matters for subselects.	12 years ago
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
unknown	599a1384af	Fix for MDEV-4144 Analysis: The reason for the inefficent plan was that Item_subselect::is_expensive() didn't detect the special case when a subquery was optimized, but had no join plan because it either has no table, or its tables have been optimized away, or the optimizer detected that the result set is empty. Solution: Identify the special cases above in the Item_subselect::is_expensive(), and consider such degenerate subqueries inexpensive.	13 years ago
unknown	2255132f20	MDEV-4056 fix. The problem was that maybe_null of Item_row and its componetes was unsynced after update_used_tables() (and so pushed_cond_guards was not initialized but then requested). Fix updates Item_row::maybe_null on update_used_tables().	13 years ago
unknown	e99aa91e90	MDEV-3928: Assertion `example' failed in Item_cache::is_expensive_processor with a 2-level IN subquery Analysis: The following call stack shows that it is possible to set Item_cache::value_cached, and the relevant value without setting Item_cache::example. #0 Item_cache_temporal::store_packed at item.cc:8395 #1 get_datetime_value at item_cmpfunc.cc:915 #2 resolve_const_item at item.cc:7987 #3 propagate_cond_constants at sql_select.cc:12264 #4 propagate_cond_constants at sql_select.cc:12227 #5 optimize_cond at sql_select.cc:13026 #6 JOIN::optimize at sql_select.cc:1016 #7 st_select_lex::optimize_unflattened_subqueries at sql_lex.cc:3161 #8 JOIN::optimize_unflattened_subqueries at opt_subselect.cc:4880 #9 JOIN::optimize at sql_select.cc:1554 The fix is to set Item_cache_temporal::example even when the value is set directly by Item_cache_temporal::store_packed. This makes the Item_cache_temporal object consistent.	13 years ago
unknown	a8bad7d900	MDEV-3902 Assertion `record_length == m_record_length' failed at Filesort_buffer::alloc_sort_buffer This bug is a duplicate of mdev-3899 so adding a test case only.	13 years ago
unknown	1b2692d0e9	MDEV-3899 Valgrind warnings (blocks are definitely lost) in filesort on IN subquery with SUM and DISTINCT Analysys: In the beginning of JOIN::cleanup there is code that is supposed to free all filesort buffers. The code assumes that the table being sorted is the first non-constant table. To get this table it calls: first_top_level_tab(this, WITHOUT_CONST_TABLES) However, first_top_level_tab() instead returned the wrong table - the first one in the plan, instead of the first non-constant table. There is no other place outside filesort() where sort buffers may be freed. As a result, the sort buffer was not freed, and there was a memory leak. Solution: Change first_top_level_tab(), to test for WITH_CONST_TABLES instead of WITHOUT_CONST_TABLES.	13 years ago
unknown	b917fb63a6	Fix bug lp:1009187, mdev-373, mysql bug#58628 Analysis: The queries in question use the [unique \| index]_subquery execution methods. These methods reuse the ref keys constructed by create_ref_for_key(). The way create_ref_for_key() works is that it doesn't store in ref.key_copy[] store_key elements that represent constants. In particular it doesn't store the store_key for NULL constants. The execution of [unique \| index]_subquery calls subselect_uniquesubquery_engine::copy_ref_key, which in addition to copy the left IN argument into a index lookup key, is supposed to detect if the left IN argument contains NULLs. Since the store_key for the NULL constant is not copied into the key array, the null is not detected, and execution erroneously proceeds as if it should look for a complete match. Solution: The solution (unlike MySQL) is to reuse already computed information about NULL presence. Item_in_optimizer::val_int already finds out if the left IN operand contains NULLs. The fix propagates this to the execution methods subselect_[unique \| index]subquery_engine::exec so it knows if there were NULL values independent of the presence of keys. In addition the patch siplifies copy_ref_key() and the logic that hanldes the case of NULLs in the left IN operand.	13 years ago
unknown	88d3d853f4	Fix bug lp:1008773 Analysis: Queries with implicit grouping (there is aggregate, but no group by) follow some non-obvious semantics in the case of empty result set. Aggregate functions produce some special "natural" value depending on the function. For instance MIN/MAX return NULL, COUNT returns 0. The complexity comes from non-aggregate expressions in the select list. If the non-aggregate expression is a constant, it can be computed, so we should return its value, however if the expression is non-constant, and depends on columns from the empty result set, then the only meaningful value is NULL. The cause of the wrong result was that for subqueries the optimizer didn't make a difference between constant and non-constant ones in the case of empty result for implicit grouping. Solution: In all implementations of Item_subselect::no_rows_in_result() check if the subquery predicate is constant. If it is constant, do not set it to the default value for implicit grouping, instead let it be evaluated.	14 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	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
Sergei Golubchik	54f9fe6c8b	lp:938977 - Query performance with join/index super slow on MariaDB 5.3.4RC make sure that stored routines are evaluated (that is, de facto - cached) in convert_const_to_int(). revert the fix for lp:806943 because it cannot be repeated anymore. add few tests for convert_const_to_int()	14 years ago
Sergey Petrunya	914245ccd8	BUG#934597: Assertion `! is_set()' failed in Diagnostics_area::set_ok_status(THD... - After the exec_const_cond->val_int() call, check for error and return. (if we don't do it, we will eventually hit an error when trying to set status OK in the diagnostics area, which already has an error status).	14 years ago
Igor Babaev	2b1f0b8757	Back-ported the patch of the mysql-5.6 code line that 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.	14 years ago
unknown	072073c09e	Backport of WL#5953 from MySQL 5.6 The patch differs from the original MySQL patch as follows: - All test case differences have been reviewed one by one, and care has been taken to restore the original plan so that each test case executes the code path it was designed for. - A bug was found and fixed in MariaDB 5.3 in Item_allany_subselect::cleanup(). - ORDER BY is not removed because we are unsure of all effects, and it would prevent enabling ORDER BY ... LIMIT subqueries. - ref_pointer_array.m_size is not adjusted because we don't do array bounds checking, and because it looks risky. Original comment by Jorgen Loland: ------------------------------------------------------------- WL#5953 - Optimize away useless subquery clauses For IN/ALL/ANY/SOME/EXISTS subqueries, the following clauses are meaningless: * ORDER BY (since we don't support LIMIT in these subqueries) * DISTINCT * GROUP BY if there is no HAVING clause and no aggregate functions This WL detects and optimizes away these useless parts of the query during JOIN::prepare()	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
Igor Babaev	b4b7d941fe	Fixed LP bug #889750 . If the optimizer switch 'semijoin_with_cache' is set to 'off' then join cache cannot be used to join inner tables of a semijoin. Also fixed a bug in the function check_join_cache_usage() that led to wrong output of the EXPLAIN commands for some test cases.	14 years ago
unknown	511459bd14	Enable subquery materialization=ON by default.	14 years ago
Sergey Petrunya	47861a6577	Change the default @@optimizer_switch settings: - semijoin=on - firstmatch=on - loosescan=on	14 years ago
unknown	6498687325	Fix bug lp:833702 Analysis: Equality propagation propagated the constant '7' into args[0] of the Item_in_optimizer that stands for the "< ANY" predicate. At the same the min/max subquery rewrite swapped the order of the left and right operands of the "<" predicate, but used Item_in_subselect::left_expr. As a result, when the <ANY predicate is executed early in the execution phase as a contant condition, instead of a constant right (swapped) argument of the < predicate, there was a field (t3.a). This field had no data, since the whole predicate is considered constant, and it is evaluated before any tables are read. Having junk in the field row buffer produced wrong result Solution: Fix create_swap to pick the correct Item_in_optimizer left argument.	14 years ago
Igor Babaev	2162704829	Moved the test case for bug 879939 to derived_view.test where it belongs to.	14 years ago
Michael Widenius	fa36a7426b	Fixed lp:879939 "assertion in ha_maria::enable_indexes with derived_with_keys=on" Honor unique/not unique when creating keys for internal tempory tables. Added new variables to be used to limit how keys are created for internal temporary tables. include/maria.h: Added maria_max_key_length() and maria_max_key_segments() include/myisam.h: Added myisam_max_key_length() and myisam_max_key_segments() mysql-test/r/mysql.result: Drop all used tables mysql-test/r/subselect4.result: Added test case for lp:879939 mysql-test/t/mysql.test: Drop all used tables mysql-test/t/subselect4.test: Added test case for lp:879939 sql/mysql_priv.h: Added internal_tmp_table_max_key_length and internal_tmp_table_max_key_segments to be used to limit how keys for derived tables are created. sql/mysqld.cc: Added internal_tmp_table_max_key_length and internal_tmp_table_max_key_segments to be used to limit how keys for derived tables are created. sql/share/errmsg.txt: Added new error message for internal errors sql/sql_select.cc: Give error if we try to create a wrong key (this error should never happen) Honor unique/not unique when creating keys for internal tempory tables. storage/maria/ha_maria.cc: Added change_table_ptr() to ensure that external_ref points always to the correct table. (Not having this caused an assert in the included test) storage/maria/ha_maria.h: Added change_table_ptr() to ensure that external_ref points always to the correct table. storage/maria/ma_check.c: Fixed bug in Duplicate key error printing (now row position is printed correctly) storage/maria/ma_create.c: maria_max_key_length() -> _ma_max_key_length() storage/maria/ma_info.c: Added extern function maria_max_key_length() to calculate the max key length based on current block size. storage/maria/ma_open.c: maria_max_key_length() -> _ma_max_key_length() storage/maria/maria_def.h: maria_max_key_length() -> _ma_max_key_length() storage/myisam/ha_myisam.cc: Added change_table_ptr() to ensure that external_ref points always to the correct table. (Not having this caused an assert in the included test) storage/myisam/ha_myisam.h: Added change_table_ptr() to ensure that external_ref points always to the correct table.	14 years ago
Sergey Petrunya	acf27225b5	Post-merge fixes: - Fix derived_view.test to work, and enable it - Let subselect*.test do "DROP TABLE IF EXISTS" before they attempt to create the table.	14 years ago
Michael Widenius	64d6cbe556	Removed duplicate test	14 years ago
unknown	c1a6dbe5b2	Fixed bug lp:825018 Analysis: During the first execution of the query through the stored procedure, the optimization phase calls substitute_for_best_equal_field(), which calls Item_in_optimizer::transform(). The latter replaces Item_in_subselect::left_expr with args[0] via assignment. In this test case args[0] is an Item_outer_ref which is created/deallocated for each re-execution. As a result, during the second execution Item_in_subselect::left_expr pointed to freed memory, which resulted in a crash. Solution: The solution is to use change_item_tree(), so that the origianal left expression is restored after each execution.	14 years ago
unknown	c9e236828e	Fix bug lp:782305 Analysis: Both the wrong result and the valgrind warning were a result of incomplete cleanup of the MIN/MAX subquery rewrite. At the first execution of the query, the non-aggregate subquery is transformed into an aggregate MIN/MAX subquery. During the fix_fields phase of the MIN/MAX function, it sets the property st_select_lex::with_sum_func to true. The second execution of the query finds this flag to be ON. When optimization reaches the same MIN/MAX subquery transformation, it tests if the subquery is an aggregate or not. Since select_lex->with_sum_func == true from the previous execution, the transformation executes the second branch that handles aggregate subqueries. This substitutes the subquery Item into a Item_maxmin_subselect. At the same time elsewhere it is assumed that the subquery Item is of type Item_allany_subselect. Ultimately this results in casting the actual object to the wrong class, and calling the wrong any_value() method from empty_underlying_subquery(). Solution: Cleanup the st_select_lex::with_sum_func property in the case when the MIN/MAX transformation was performed for a non-aggregate subquery, so that the transformation can be repeated.	14 years ago
unknown	53681ee5db	Fix bug lp:777691 Analysis: For some of the re-executions of the correlated subquery the where clause is false. In these cases the execution of the subquery detects that it must generate a NULL row because of implicit grouping. In this case the subquery execution reaches the following code in do_select(): while ((table= li++)) mark_as_null_row(table->table); This code marks all rows in the table as complete NULL rows. In the example, when evaluating the field t2.f10 for the second row, all bits of Field::null_ptr[0] are set by the previous call to mark_as_null_row(). Then the call to Field::is_null() returns true, resulting in a NULL for the MAX function. Thus the lines above are not suitable for subquery re-execution because mark_as_null_row() changes the NULL bits of each table field, and there is no logic to restore these fields. Solution: The call to mark_as_null_row() was added by the fix for bug lp:613029. Therefore removing the fix for lp:613029 corrects this wrong result. At the same time the test for lp:613029 behaves correctly because the changes of MWL#89 result in a different execution path where: - the constant subquery is evaluated via JOIN::exec_const_cond - detecting that it has an empty result triggers the branch if (zero_result_cause) return_zero_rows() - return_zero_rows() calls mark_as_null_row().	14 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
unknown	e98aecc2e0	Test for bug lp:611382 The bug itself has been fixed by MWL#89.	15 years ago
unknown	57432d0c64	Test case for bug lp:611396 The bug itself has been fixed by MWL#89.	15 years ago
unknown	0f36ab3a52	Test for bug lp:612543 The bug itself has been fixed by MWL#89.	15 years ago
unknown	5f5cbf7684	Test case for bug lp:611690 The bug itself has been fixed by MWL#89.	15 years ago
unknown	4128ec4852	Fix bug lp:806943 Analysis: This bug is yet another incarnation of the generic problem where optimization of the outer query triggers evaluation of a subquery, and this evaluation performs a destructive change to the subquery plan. Specifically a temp table is created for the DISTINCT operation that replaces the original subquery table. Later, select_describe() attempts to print the table name, however, there is no corresponding TABLE_LIST object to the internal temp table, so we get a crash. Execution works fine because it is not interested in the corresponding TABLE_LIST object (or its name). Solution: Similar to other such bugs, block the evaluation of expensive Items in convert_const_to_int().	15 years ago
Sergey Petrunya	c1de6f8b77	Change the default @@optimizer_switch setting from semijoin=on,firstmatch=on,loosescan=on to semijoin=off,firstmatch=off,loosescan=off Adjust the testcases: - Modify subselect*.test and join_cache.test so that all tests use the same execution paths as before (i.e. optimizations that are being tested are enabled) - Let all other test files run with the new default settings (i.e. with new optimizations disabled) - Copy subquery testcases from these files into t/subselect_extra.test which will run them with new optimizations enabled.	15 years ago
unknown	59784abead	Fix LP bug lp:802979 Analysis: This bug consists of two related problems that are result of too early evaluation of single-row subqueries during the optimization phase of the outer query. Several optimizer code paths try to evaluate single-row subqueries in order to produce a constant and use that constant for further optimzation. When the execution of the subquery peforms destructive changes to the representation of the subquery, and these changes are not anticipated by the subsequent optimization phases of the outer query, we tipically get a crash or failed assert. Specifically, in this bug the inner-most suqbuery with DISTINCT triggers a substitution of the original JOIN object by a single-table JOIN object with a temp table needed to perform the DISTINCT operation (created by JOIN::make_simple_join). This substitution breaks EXPLAIN because: a) in the first example JOIN::cleanup no longer can reach the original table of the innermost subquery, and close all indexes, and b) in this second test query, EXPLAIN attempts to print the name of the internal temp table, and crashes because the temp table has no name (NULL pointer instead). Solution: a) fully disable subquery evaluation during optimization in all cases - both for constant propagation and range optimization, and b) change JOIN::join_free() to perform cleanup irrespective of EXPLAIN or not.	15 years ago
Sergey Petrunya	9482e387e6	Change optimizer_use_mrr=auto\|disable\|force to be optimizer_switch flags mrr=on\|off and mrr_cost_based=on\|off.	15 years ago
Sergey Petrunya	f0038da8f6	Post-merge fixes part #1 .	15 years ago
unknown	742dfc92a2	MWL#89: Address review feedback (by Sergey Petrunia) mysql-test/r/subselect4.result: Moved test case for LP BUG#718593 into the correct test file subselect_mat_cost_bugs.test. mysql-test/t/subselect4.test: Moved test case for LP BUG#718593 into the correct test file subselect_mat_cost_bugs.test.	15 years ago
unknown	4a9c027ad8	Fix LP BUG#778413 Analysis: The subquery is evaluated first during ref-optimization of the outer query because the subquery is considered constant from the perspective of the outer query. Thus an attempt is made to evaluate the MAX subquery and use the new constant to drive an index nested loops join. During this evaluation the inner-most subquery replaces the JOIN_TAB with a new one that fetches the data from a temp table. The function select_describe crashes at the lines: TABLE_LIST *real_table= table->pos_in_table_list; item_list.push_back(new Item_string(real_table->alias, strlen(real_table->alias), cs)); because 'table' is a temp table, and it has no corresponding table reference. This 'real_table' is NULL, and real_table->alias results in a crash. Solution: In the spirit of MWL#89 prevent the evaluation of expensive predicates during optimization. This patch prevents the evaluation of expensive predicates during ref optimization. sql/item_subselect.h: Remove unused class member. Not needed for the fix, but noticed now and removed.	15 years ago
unknown	b757f73492	Fix LP BUG#777597 Analysis: During optimization of the subquery, in the call chain: update_ref_and_keys -> add_key_fields -> merge_key_fields -> Item_direct_ref::is_null -> Item_cache::is_null The call to Item_cache::is_null() returns TRUE, which is wrong. This results in Item_null replacing the field 'f3' in the KEY_FIELD, then this Item_null is used for index access, producing a wrong result. The reason why Item_cache::is_null returns wrong result is that this Item_cache object is a cache of the left operand of IN, and was updated in Item_in_optimizer::val_int. In MWL#89 the latter method is called during the execution phase, which is after we optimize the subquery. Therefore during the optization phase the left operand cache of IN was not updated. Solution: Update the left operand cache during optimization if it is a constant. This bug fix also discoveres and fixes a wrong IF statement in convert_constant_item().	15 years ago
unknown	ee3b7b56e4	Fix LP BUG#772309 Analysis: The method st_select_lex::optimize_unflattened_subqueries() incorrectly propagated to each subquery the complete select_options flag set for the whole query. Among other flags in select_options, this propagated incorrectly the STRAIGHT_JOIN flag from the upper query to the subquery. Solution: During EXPLAIN set only the SELECT_DESCRIBE bit in the select_options of the subquery.	15 years ago
unknown	0278b06e6b	LP BUG#715759 Pushing test case only. The bug itself was fixed by the combined patches for LP BUG#717577 and LP BUG#776274.	15 years ago
unknown	0f4236659c	Fix LP BUG#718593 Analysis: Build_equal_items_for_cond() rewrites the WHERE clause in such a way, that it may merge the list join->cond_equal->current_level with the list of child Items in an AND condition of the WHERE clause. The place where this is done is: static COND build_equal_items_for_cond(THD thd, COND cond, COND_EQUAL inherited) { ... if (and_level) { args->concat(&eq_list); args->concat((List<Item> *)&cond_equal.current_level); } ... } As a result, later transformations on the WHERE clause may change the structure of the list join->cond_equal->current_level without knowing this. Specifically in this bug, Item_in_subselect::inject_in_to_exists_cond creates a new AND of the old WHERE clause and the IN->EXISTS conditions. It then calls fix_fields() for the new AND. Among other things, fix_fields flattens all nested ANDs into one by merging the AND argument lists. When there is a cond_equal for the JOIN, its list of Item_equal objects is attached to the end of the original AND. When a lower-level AND is merged into the top-level one, the argument list of the lower-level AND is concatenated to the list of multiple equalities in the upper-level AND. As a result, when substitute_for_best_equal_field processes the multiple equalities, it turns out that the multiple equality list contains the Items from the lower-level AND which were concatenated to the end of the join->cond_equal->current_level list. This results in a crash because this list must not contain any other Items except for the previously found Item_equal ones. Solution: When performing IN->EXIST predicate injection, and the where clause is an AND, detach the list of Item_equal objects before calling fix_fields on the injected where clause. After fix_fields is done, reattach back the multiple equalities list to the end of the argument list of the new AND.	15 years ago
unknown	43acceeb47	Fix LP BUG#715069 Analysis: The wrong result is a consquence of sorting the subquery result and then selecting only the first row due to the artificial LIMIT 1 introduced by the fix_fields phase. Normally, if there is an ORDER BY in a subquery, the ORDER is removed (Item_in_subselect::select_in_like_transformer), however if a GROUP BY is transformed into ORDER, this happens later, after the removal of the ORDER clause of subqueries, so we end up with a subquery with an ORDER clause, and an artificially added LIMIT 1. The reason why the same works in the main 5.3 without MWL#89, is that the 5.3 performs all subquery transformations, including IN->EXISTS before JOIN::optimize(). The beginning of JOIN::optimize does: if (having \|\| (select_options & OPTION_FOUND_ROWS)) select_limit= HA_POS_ERROR; which sets the limit back to infinity, thus 5.3 sorts the whole subquery result, and IN performs the lookup into all subquery result rows. Solution: Sorting of subqueries without LIMIT is meaningless. Since LIMIT in subqueries is not supported, the patch removes sorting by setting join->skip_sort_order= true for each subquery JOIN object. This improves a number of execution plans to not perform unnecessary sorting at all.	15 years ago

1 2 3

111 Commits (5e61e1716e763315009318081fba5994b8910242)