mariadb

Commit Graph

Author	SHA1	Message	Date
Sergey Petrunya	255fd6c929	Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.	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
unknown	54caeee5d6	Making subquery cache on by default.	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	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
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().	15 years ago
Sergey Petrunya	85571ea76c	Disable LooseScan and FirstMatch when outer joins are present.	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
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	4493197125	Followup to previous commit: - Update test results - Fix a problem with PS: = convert_subq_to_sj() should not save where to prep_where or on_expr to prep_on_expr. = After an unmerged subquery predicate has been pulled, it should call fix_after_pullout() for outer_refs.	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	aa551f1b9e	Post-merge fixes part#2	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
unknown	5ed997904e	Test case for LP BUG#715062. There is no patch because the bug cannot be reproduced any more.	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
unknown	7999f40a99	Fix LP BUG#613029 Analysis: There are two code paths through which JOIN::exec may produce an all-NULL row for an empty result set. One goes via the function return_zero_rows(), when query processing detectes early that the where clause is false, the other one is via do_select() in the case of join execution. In the case of do_select(), the problem was that the executioner didn't set TABLE::null_row to 1. As result when sending the only result row, the evaluation of each field didn't detect that all non-aggregated fields are NULL, because Field::is_null returned true, after checking that field->table->null_row was false. Given that the each non-aggregated field was not considered NULL, select_result::send_data sent whatever was in the buffer of each field. However, since there was no actual data in the field buffer, send_data() accessed and sent whatever junk was in the field's data buffer. Solution: Similar to the analogous case in return_zero_rows() mark all tables that their current row is NULL before sending the artificailly created NULL row.	15 years ago
unknown	ec23949158	Fix LP BUG#715738 Analysis: A query with implicit grouping is one with aggregate functions and no GROUP BY clause. MariaDB inherits from MySQL an SQL extenstion that allows mixing aggregate functions with non-aggregate fields. If a query with such mixed select clause produces an empty result set, the meaning of aggregate functions is well defined - either NULL (MIN, MAX, etc.), or 0 (count(*)). However the non-aggregated fields must also have some value, and the only reasonable value in the case of empty result is NULL. The cause of the many wrong results was that if a field is declared as non-nullable (e.g. because it is a PK or NOT NULL), the semantic analysis and the optimization phases treat this field as non-nullable, and generate all related query plan elements based on this assumption. Later during execution, these incorrectly configured/generated query plan elements result in a wrong result because the selected fields are not null due to the not-null assumption during optimization. Solution: Detect before the context analysys phase that a query uses implicit grouping with mixed aggregates/non-aggregates, and set all fields as nullable. The parser already walks the SELECT clause, and already sets Item::with_sum_func for Items that reference aggreagate functions. The patch adds a symmetric Item::with_field so that all Items that reference an Item_field are marked during their construction at parse time in the same way as with aggregate function use.	15 years ago
unknown	adce16f96f	Fix LP BUG#718763 Analysis: The reason for the crash was that the inner subquery was executed via a scan on a final temporary table applied after all other operations. This final operation is implemented by changing the contents of the JOIN object of the subquery to represent a table scan over the temp table. At the same time query optimization of the outer subquery required evaluation of the inner subquery, which happened before the actual EXPLAIN. The evaluation left the JOIN object of the inner subquery in the changed state, where it represented a table scan over a temp table, and EXPLAIN crashed because the temp table is not associated with any table reference (TABLE_LIST object). The reason the JOIN was not restored was because its saving/restoration was controlled by the join->select_lex->uncacheable flag, which was not set in the case of materialization. Solution: In the methods Item_in_subselect::[single \| row]_value_transformer() set: select_lex->uncacheable\|= UNCACHEABLE_EXPLAIN; In addition, for symmetry, change: master_unit->uncacheable\|= UNCACHEABLE_EXPLAIN; instead of UNCACHEABLE_DEPENDENT because if a subquery was not dependent initially, the changed methods do not change this fact. The subquery may later become correlated if it is transformed to an EXISTS query, but it may stay uncorrelated if executed via materialization.	15 years ago
Sergey Petrunya	0f265b8251	BUG#723822: Crash in get_constant_key_infix with EXISTS ( SELECT .. DISTINCT ) - Make get_constant_key_infix() take into account that there may be SEL_TREEs with type=SEL_ARG::MAYBE_KEY, which it cannot process, because they are not real ranges but rather indications that we might have been able to construct a range if we had values for some other tables' fields. (check_quick_select() already has such check)	15 years ago
Sergey Petrunya	e431f106b9	BUG#716293: "Range checked for each record" is not used if condition refers to outside of subquery - Assume that outside subquery references are known when doing "Range-checked-for-each-record" check.	15 years ago
unknown	648e604615	MWL#89 Adjusted test cases in accordance with the implementation.	15 years ago
Sergey Petrunya	9dc14aa76e	Backport testcase: BUG#45863 "Assertion failed: (fixed == 0), function fix_fields(), file item.cc, line 4448" (The fix was backported with subquery code backport)	15 years ago
Martin Hansson	3c5662c195	Bug#58207: invalid memory reads when using default column value and tmptable needed The function DEFAULT() works by modifying the the data buffer pointers (often referred to as 'record' or 'table record') of its argument. This modification is done during name resolution (fix_fields().) Unfortunately, the same modification is done when creating a temporary table, because default values need to propagate to the new table. Fixed by skipping the pointer modification for fields that are arguments to the DEFAULT function.	15 years ago
Martin Hansson	ffdeb06272	Bug#54568: create view cause Assertion failed: 0, file .\item_subselect.cc, line 836 IN quantified predicates are never executed directly. They are rather wrapped inside nodes called IN Optimizers (Item_in_optimizer) which take care of the execution. However, this is not done during query preparation. Unfortunately the LIKE predicate pre-evaluates constant right-hand side arguments even during name resolution. Likely this is meant as an optimization. Fixed by not pre-evaluating LIKE arguments in view prepare mode. Back-ported to 5.0s	15 years ago
unknown	620aea4fde	Fix LP BUG#682683 Analysis: The fix for LP BUG#680846 avoids evaluation of constant expressions with subqueries in the GROUP/ORDER clauses in the procedure remove_const(). The purpose of remove_const is to remove constant expressions in the GROUP/ORDER clauses. In order delay until execution the evaluation of such subqueries, they were not removed in the GROUP/ORDER clause. As a result temp table creation during execution attempted to create a column in the temp table for each constant GROUP/ORDER expression. However, the logic in create_tmp_table is to not create temp table columns for constant items. The crash was due to a group Item without a corresponding column in the temp table for GROUP BY. Solution: The patch adds back removal of constant expressions with subqueries. In order for such expressions to be evaluated, so that the server can ensure that such subquries return 1 row, the evaluation of these expressions is delayed until execution.	15 years ago
unknown	1b3336dc30	Fix LP BUG#680943 Analysis: The problem lies in filesort.cc:find_all_keys(). When find_all_keys() is called for the outer query, it resets all of the tree sets of fields - [read,write,vcol]_set and recomputes them with respect to sorting. However, in the loop for each current record the procedure calls select->skip_record(thd), which evaluates the where clause, which in turns evaluates the subquery. The JOIN evaluation of the subquery eventually calls Field_long::val_int to evaluate the field alias1.f1. The assertion condition "bitmap_is_set(table->read_set, field_index)" fails, because the outer query changed the read_set of table "alias1". Solution: Restore the original read_set of the table before calling SQL_SELECT::skip_record, then revert back to the read_set used in find_all_keys.	15 years ago
unknown	6dfca7d346	Fix LP BUG#680846 Analysis: JOIN::optimize performs constant optimization of GROUP by clauses by calling remove_const(): group_list= remove_const(this, (old_group_list= group_list), conds, rollup.state == ROLLUP::STATE_NONE, &simple_group); If it turns out that a GROUP clause references a field that is computed by a single-row subquery, then the said optimization performs premature execution of the subquery referenced by the group clause. Solution: Block the evaluation of subqueries similarly to the approach for the WHERE and JOIN..ON clauses.	15 years ago
unknown	2fa5df5f4e	Fix LP BUG#680038 Analysis: Single-row subqueries are not considered expensive and are evaluated both during EXPLAIN in to detect errors like "Subquery returns more than 1 row", and during optimization to perform constant optimization. The cause for the failed ASSERT is in JOIN::join_free, where we set bool full= (!select_lex->uncacheable && !thd->lex->describe); Thus for EXPLAIN statements full == FALSE, and as a result the call to JOIN::cleanup doesn't call JOIN_TAB::cleanup which should have called table->disable_keyread(). Solution: Consider all kinds of subquery predicates as expensive.	15 years ago
unknown	fb215f76bb	Fix LP BUG#680005 Analysis: This another instance of the problem fixed in LP BUG#675981 - evaluation of subqueries during EXPLAIN when the subquery plan is incomplete because JOIN::optimize() generally doesn't create complete execution plans for EXPLAIN statements. In this case the call path is: mysql_explain_union -> outer_join.exec -> outer_join.init_execution -> create_sort_index -> filesort -> find_all_keys -> SQL_SELECT::skip_record -> outer_where_clause.val_int -> ... -> subselect_join.exec -> ... -> sub_select_cache When calling sub_select_cache JOIN_TAB::cache is NULL because the cache objects are not created for EXPLAIN statements. Solution: Delay the call to init_execution() after all EXPLAIN related processing is completed. Thus init_execution() is not called at all during EXPLAIN.	15 years ago
unknown	0a31c4ffc3	Fixed LP BUG#675981 Cause: The optimize() phase for the subquery selected to use join buffering via setting JOIN_TAB::next_select= sub_select_cache in make_join_readinfo, however, the call to check_join_cache_usage() from make_join_readinfo didn't create the corresponding JOIN_CACHE_BNL object because of the condition: if ((options & SELECT_DESCRIBE) \|\| (((tab->cache= new JOIN_CACHE_BNL(join, tab, prev_cache))) && !tab->cache->init())) Since EXPLAIN for subqueries runs regular execution, the constant predicates that were delayed to be evaluated at the exec() phase, were evaluated during EXPLAIN. As a result the outer JOIN::exec called JOIN::exec for the subquery, while the subquery execution plan was no properly created, which resulted in an failed ASSERT. Fix: The patch blocks evaluation of constant expensive conditions during EXPLAIN. Notice that these conditions are "constant" with respect to the outer query, thus in general they could be arbitrarily expensive, which may result in very slow EXPLAINs.	15 years ago
unknown	bd5c45dc7a	Fix for LP BUG#676411 and MySQL BUG#52317 This is a backport of the fix for MySQL BUG#52317: Assertion failing in Field_varstring::store () at field.cc:6833 The orginal comment by Oystein is: In order for EXPLAIN to print const-refs, a Store_key_const_item object is created. This is different for normal execution of subqueries where a temporary store_key_item object is used instead. The problem is that EXPLAIN will execute subqueries. This leads to a scenario where a store_key_const_item object it told to write to its underlying field. This results in a failing assert since the write set of the underlying table does not reflect this. The resolution is to do the same trick as for store_key_item::copy_inner(). That is, temporarily change the write set to allow writes to all columns. This is only necessary in debug version since non-debug version does not contain asserts on write_set. sql/sql_select.h: Temporarily change write_set in store_key_const_item::copy_inner() to allow initialization of underlying field. This is necessary since subqueries are executed for EXPLAIN. (For normal execution, store_key_item::copy_inner is used.)	15 years ago

1 2 3

103 Commits (255fd6c9294025ced406382980b0ad51960f0971)