mariadb

Commit Graph

Author	SHA1	Message	Date
Igor Babaev	841a74a4d6	Fixed LP bug #939009 . The result of materialization of the right part of an IN subquery predicate is placed into a temporary table. Each row of the materialized table is distinct. A unique key over all fields of the temporary table is defined and created. It allows to perform key look-ups into the table. The table created for a materialized subquery can be accessed by key as any other table. The function best_access-path search for the best access to join a table to a given partial join. With some where conditions this function considers a possibility of a ref_or_null access. If such access employs the unique key on the temporary table then when estimating the cost this access the function tries to use the array rec_per_key. Yet, such array is not built for this unique key. This causes a crash of the server. Rows returned by the subquery that contain nulls don't have to be placed into temporary table, as they cannot be match any row produced by the left part of the subquery predicate. So all fields of the temporary table can be defined as non-nullable. In this case any ref_or_null access to the temporary table does not make any sense and it does not make sense to estimate such an access. The fix makes sure that the temporary table for a materialized IN subquery is defined with columns that are all non-nullable. The also ensures that any row with nulls returned by the subquery is not placed into the temporary table.	14 years ago
unknown	f6cdddf51f	Test case for bug lp:905353 The bug itself is fixed by the patch for bug lp:908269.	14 years ago
unknown	cf31ccc33c	Fix for LP BUG#908269 Wrong result with subquery in select list, EXISTS, constant MyISAM/Aria table. Problem: When building the condition for JOIN::outer_ref_cond the optimizer forgot to take into account that this condition could depend on constant tables as well.	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	7a1406f229	Fixed LP bug #904832 . Do not perform index condition pushdown for conditions containing subqueries and stored functions.	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
Sergey Petrunya	ae480437ce	Small semi-join optimization improvement: - if we're considering FirstMatch access with one inner table, and @@optimizer_switch has semijoin_with_cache flag, calculate costs as if we used join cache (because we will be able to do so)	14 years ago
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
unknown	264aaf111d	Added test suite for the LP BUG#885162 (fixed by the patch for LP BUG#859375 and LP BUG#887458).	14 years ago
unknown	625cdb8078	Fixed bug lp:825051 The cause of the wrong result was that Item_ref_null_helper::get_date() didn't use a method of the _result() family, and fetched the data for the field from the current row instead of result_field. Changed to use the correct _result() method, like to all other similar methods of Item_ref_null_helper.	14 years ago
unknown	62e7ab3ac7	Fix bugs lp:833777, lp:894397 Analysis: lp:894397 was a consequence of a prior incorrect fix of lp:833777 which didn't take into account that even when all tables are constant there may be correlated conditions, and the where clause is not equivalent to the constant conditions. Solution: When there are constant tables only, evaluate only the conditions that reference outer fields, because the constant conditions are already checked, and the where clause doesn't have other conditions than constant ones, and outer referencing ones. The fix for lp:894397 also fixes lp:833777.	14 years ago
unknown	5412e82c01	Fixed LP BUG#747278 The problem was that when we have single row subquery with no rows Item_cache(es) which represent result row was not null and being requested via element_index() returned random value. The fix is setting all Item_cache(es) in NULL before executing the query (reset() method) which guaranty NULL value of whole query or its elements requested in any way if no rows was found. set_null() method was added to Item_cache to guaranty correct NULL value in case of reseting the cache.	14 years ago
Igor Babaev	17b4e4a194	Set new default values for the optimizer switch flags 'derived_merge' and 'derived_with_keys'. Now they are set on by default.	14 years ago
Sergey Petrunya	f84dbf4b20	Semi-join optimizations code cleanup part 2: - Make EXPLAIN display "Start temporary" at the start of the fanout (it used to display at the first table whose rowid gets into temp. table which is not that useful for the user) - Updated test results (all checked)	14 years ago
unknown	6fbf8f1926	Fix for LP BUG#859375 and LP BUG#887458. Stop attempts to apply IN/ALL/ANY optimizations to so called "fake_select" (used for ordering and filtering results of union) in union subquery execution.	14 years ago
unknown	b9d6bff883	Fix test to pass on 32-bit machines by reducing the depth of subquery nestedness to less than 31 (sizeof(ulong)-1).	14 years ago
unknown	f8dbbc010f	Fix bug lp:833777 Analysis: The optimizer distinguishes two kinds of 'constant' conditions: expensive ones, and non-expensive ones. The non-expensive conditions are evaluated inside make_join_select(), and if false, already the optimizer detects empty query results. In order to avoid arbitrarily expensive optimization, the evaluation of expensive constant conditions is delayed until execution. These conditions are attached to JOIN::exec_const_cond and evaluated in the beginning of JOIN::exec. The relevant execution logic is: JOIN::exec() { if (! join->exec_const_cond->val_int()) { produce an empty result; stop execution } continue execution execute the original WHERE clause (that contains exec_const_cond) ... } As a result, when an expensive constant condition is TRUE, it is evaluated twice - once through JOIN::exec_const_cond, and once through JOIN::cond. When the expensive constant condition is a subquery, predicate, the subquery is evaluated twice. If we have many levels of subqueries, this logic results in a chain of recursive subquery executions that walk a perfect binary tree. The result is that for subquries with depth N, JOIN::exec is executed O(2^N) times. Solution: Notice that the second execution of the constant conditions happens inside do_select(), in the branch: if (join->table_count == join->const_tables) { ... } In this case exec_const_cond is equivalent to the whole WHERE clause, therefore the WHERE clause has already been checked in the beginnig of JOIN::exec, and has been found to be true. The bug is addressed by not evaluating the WHERE clause if there was exec_const_conds, and it was TRUE.	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	1d721d0106	Fix MySQL BUG#12329653 In MariaDB, when running in ONLY_FULL_GROUP_BY mode, the server produced in incorrect error message that there is an aggregate function without GROUP BY, for artificially created MIN/MAX functions during subquery MIN/MAX optimization. The fix introduces a way to distinguish between artifially created MIN/MAX functions as a result of a rewrite, and normal ones present in the query. The test for ONLY_FULL_GROUP_BY violation now tests in addition if a MIN/MAX function was part of a MIN/MAX subquery rewrite. In order to be able to distinguish these MIN/MAX functions, the patch introduces an additional flag in Item_in_subselect::in_strategy - SUBS_STRATEGY_CHOSEN. This flag is set when the optimizer makes its final choice of a subuqery strategy. In order to make the choice consistent, access to Item_in_subselect::in_strategy is provided via new class methods. ****** Fix MySQL BUG#12329653 In MariaDB, when running in ONLY_FULL_GROUP_BY mode, the server produced in incorrect error message that there is an aggregate function without GROUP BY, for artificially created MIN/MAX functions during subquery MIN/MAX optimization. The fix introduces a way to distinguish between artifially created MIN/MAX functions as a result of a rewrite, and normal ones present in the query. The test for ONLY_FULL_GROUP_BY violation now tests in addition if a MIN/MAX function was part of a MIN/MAX subquery rewrite. In order to be able to distinguish these MIN/MAX functions, the patch introduces an additional flag in Item_in_subselect::in_strategy - SUBS_STRATEGY_CHOSEN. This flag is set when the optimizer makes its final choice of a subuqery strategy. In order to make the choice consistent, access to Item_in_subselect::in_strategy is provided via new class methods.	14 years ago
unknown	511459bd14	Enable subquery materialization=ON by default.	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	a70f7aa5fe	Backported the fix and the test case for bug 12822678 from the mysql-5.6 code line. Fixed a bug in select_describe. Adjusted results for affected test cases.	14 years ago
Sergei Golubchik	9f6e24a05a	lp:817966 int_column IN (string_constant) restore the status quo from before the microsecond patch	14 years ago
unknown	54caeee5d6	Making subquery cache on by default.	14 years ago
unknown	8b062c1fef	Fix of LP BUG#780386. ALL subquery should return TRUE if subquery rowa set is empty independently of left part. The problem was that Item_func_(eq,ne,gt,ge,lt,le) do not call execution of second argument if first is NULL no in this case subquery will not be executed and when Item_func_not_all calls any_value() of the subquery or aggregation function which report that there was rows. So for NULL < ALL (SELECT...) result was FALSE instead of TRUE. Fix is just swapping of arguments of Item_func_(eq,ne,gt,ge,lt,le) (with changing the operation if it is needed) so that result will be the same (for examole a < b is equal to b > a). This fix exploit the fact that first argument will be executed in any case.	15 years ago
unknown	37a8497d49	LP BUG#823169 fix. For ANY subqueries NULLs should be ignored (if there is other values) when finding max min. For ALL subqueries NULLs should be saved if they found. Optimisation for ALL suqbueries if NULL is possible in the SELECT list with max/min aggregate function switched off. Some test changed where NULL is not used but optimization with max/min aggregate function important so NOT NULL added. mysql-test/r/explain.result: Forced old optimization. mysql-test/r/subselect.result: Forced old optimization. New test suite. mysql-test/t/explain.test: Forced old optimization. mysql-test/t/subselect.test: Forced old optimization. New test suite. sql/item_subselect.cc: Store converted subquery type. Switch off aggregate function optimisation for ALL and nulls. sql/sql_class.cc: Fixed NULL comparison. sql/sql_class.h: Store converted subquery type.	15 years ago
unknown	2df1914791	Fix bug lp:827416 Analysis: Constant table optimization of the outer query finds that the right side of the equality is a constant that can be used for an eq_ref access to fetch one row from t1, and substitute t1 with a constant. Thus constant optimization triggers evaluation of the subquery during the optimize phase of the outer query. The innermost subquery requires a plan with a temporary table because with InnoDB tables the exact count of rows is not known, and the empty tables cannot be optimzied way. JOIN::exec for the innermost subquery substitutes the subquery tables with a temporary table. When EXPLAIN gets to print the tables in the innermost subquery, EXPLAIN needs to print the name of each table through the corresponding TABLE_LIST object. However, the temporary table created during execution doesn't have a corresponding TABLE_LIST, so we get a null pointer exception. Solution: The solution is to forbid using expensive constant expressions for eq_ref access for contant table optimization. Notice that eq_ref with a subquery providing the value is still possible during regular execution.	15 years ago
Igor Babaev	aab970f5e1	Fixed LP bug #826279 . When the WHERE/HAVING condition of a subquery has been transformed by the optimizer the pointer stored the 'where'/'having' field of the SELECT_LEX structure used for the subquery must be updated accordingly. Otherwise the pointer may refer to an invalid item. This can lead to the reported assertion failure for some queries with correlated subqueries	15 years ago
unknown	6b70cc538b	Fix bug lp:813473 The bug is a duplicate of MySQL's Bug#11764086, however MySQL's fix is incomplete for MariaDB, so this fix is slightly different. In addition, this patch renames Item_func_not_all::top_level() to is_top_level_item() to make it in line with the analogous methods of Item_in_optimizer, and Item_subselect. Analysis: It is possible to determine whether a predicate is NULL-rejecting only if it is a top-level one. However, this was not taken into account for Item_in_optimizer. As a result, a NOT IN predicate was erroneously considered as NULL-rejecting, and the NULL-complemented rows generated by the outer join were rejected before being checked by the NOT IN predicate. Solution: Change Item_in_optimizer to be considered as NULL-rejecting only if it a top-level predicate.	15 years ago
unknown	fede2ee7f1	Bug lp:781508: Take relevant test cases from MySQL 5.6 feature preview trees Identified all test cases in the MySQL file subquery.inc that are not present in MariaDB. This patch adds the test cases that are: - not present in MySQL 5.5, and - already fixed in MariaDB 5.3 The patch adds test cases for the following mysql-trunk bugs: - Bug#12763207 - not a bug, mysql-trunk, added test case - BUG#50257 - not a bug, mysql-trunk, added test case - Bug 11765699 - not a bug, mysql-trunk, added test case - BUG#12616253 - not a bug, mysql-trunk, added test case The comparison was based on the following version of mysql-trunk: revno: 3350 [merge] committer: Marko Mäkelä <marko.makela@oracle.com> branch nick: mysql-trunk timestamp: Mon 2011-08-08 12:42:09 +0300 message: Merge mysql-5.5 to mysql-trunk.	15 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.	15 years ago
Igor Babaev	63abf00a62	Made the optimizer switches 'derived_merge' and 'derived_with_keys' off by default.	15 years ago
unknown	2b6a23447b	Fix of LP BUG#780386. ALL subquery should return TRUE if subquery rowa set is empty independently of left part. The problem was that Item_func_(eq,ne,gt,ge,lt,le) do not call execution of second argument if first is NULL no in this case subquery will not be executed and when Item_func_not_all calls any_value() of the subquery or aggregation function which report that there was rows. So for NULL < ALL (SELECT...) result was FALSE instead of TRUE. Fix is just swapping of arguments of Item_func_(eq,ne,gt,ge,lt,le) (with changing the operation if it is needed) so that result will be the same (for examole a < b is equal to b > a). This fix exploit the fact that first argument will be executed in any case. mysql-test/r/subselect.result: The test suite added. mysql-test/r/subselect_no_mat.result: The test suite added. mysql-test/r/subselect_no_opts.result: The test suite added. mysql-test/r/subselect_no_semijoin.result: The test suite added. mysql-test/r/subselect_scache.result: The test suite added. mysql-test/t/subselect.test: The test suite added. sql/item_cmpfunc.cc: Swap arguments creation methods added. sql/item_cmpfunc.h: Swap arguments creation methods added. sql/item_subselect.cc: Swap arguments of the comparison.	15 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
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
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	e2eafc3bd1	Fix buildbot failures: - JOIN::prepare would have set JOIN::table_count to incorrect value (bad merge of MWL 106) - optimize_keyuse() would use table-bit as table number (the change in optimize_keyuse is also the reason for query plan changes. Not expected to have much effect because only handles cases of no index statistics) - st_select_lex::register_dependency_item() ignored the fact that some of the selects on the dependency paths could have been merged to their parents (because they were mergeable VIEWs) - Undo the incorrect fix in Item_subselect::recalc_used_tables(): do not call fix_after_pullout() for Item_subselect::Ref_to_outside members.	15 years ago
Igor Babaev	db0c340601	Fixed LP bug #793436 . When looking for the execution plan of a derived table to be materialized JOIN::optimize finds out that all joined tables of the derived table contain not more than one row then the derived table should be maretialized at the optimization stage. Added a test case for the bug. Adjusted results in other test cases.	15 years ago
Sergey Petrunya	aa551f1b9e	Post-merge fixes part#2	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
Sergey Petrunya	30575353b6	BUG#779885: Crash in eliminate_item_equal with materialization=on in maria-5.3 - In eliminate_item_equal(), we could end up in a situation where: = The multiple equality has a constant C1 (and so it is the "head item") = The join order was such that we've generated "sj_inner_table1=C1" equality, and now are looking to generate "sj_inner_table2_=..." equality. When looking for what should be the other member of equality, we run Item *head_item= current_sjm? current_sjm_head: head; which sees current_sjm!=NULL, and takes current_sjm_head (which is NULL because the constant C1 is the head for all cases). - Fixed in a trivial way: take current_sjm_head if we don't have constant.	15 years ago
unknown	f48784754a	MWL#89 Adjusted test results after merge.	15 years ago
Igor Babaev	e3e2358fd2	Fixed LP bug #751350 . The third parameter in the call of make_cond_for_table() that built the pushed condition containing only outer references was incorrect. This condition appeared for the first time in the patch fixing bug 729039.	15 years ago
Oleksandr Byelkin	7b797fe66d	Moving max/min optimization from prepare to optimization phase. MWL#148 mysql-test/r/explain.result: fixed results (new item) mysql-test/r/subselect.result: fixed results (new item) mysql-test/r/subselect_no_mat.result: fixed results (new item) mysql-test/r/subselect_no_opts.result: fixed results (new item) mysql-test/r/subselect_no_semijoin.result: Fixed results (new item) mysql-test/suite/pbxt/r/subselect.result: Fixed results (new item) mysql-test/t/explain.test: Fixed results (correct behaviour) sql/item_cmpfunc.cc: Pass through for max/min sql/item_subselect.cc: moving max/min sql/item_subselect.h: moving max/min sql/mysql_priv.h: new uncacheble flags added sql/opt_subselect.cc: maxmin moved. sql/opt_subselect.h: New function for maxmin. sql/sql_class.h: debug code sql/sql_lex.cc: Fixed flags. Limit setting fixed. sql/sql_lex.h: 2 new flags. sql/sql_select.cc: Prepare divided on 2 function to be able recollect some info after transformation. sql/sql_select.h: Prepare divided on 2 functions.	15 years ago
Tor Didriksen	1cf483aa58	Bug#12329653 - EXPLAIN, UNION, PREPARED STATEMENT, CRASH, SQL_FULL_GROUP_BY The query was re-written after we had tagged it with NON_AGG_FIELD_USED. Remove the flag before continuing. mysql-test/r/explain.result: Update test case for Bug#48295. mysql-test/r/subselect.result: New test case. mysql-test/t/explain.test: Update test case for Bug#48295. mysql-test/t/subselect.test: New test case. sql/item.cc: Use accessor functions for non_agg_field_used/agg_func_used. sql/item_subselect.cc: Remove non_agg_field_used when we rewrite query '1 < some (...)' => '1 < max(...)' sql/item_sum.cc: Use accessor functions for non_agg_field_used/agg_func_used. sql/mysql_priv.h: Remove unused #defines. sql/sql_lex.cc: Initialize new member variables. sql/sql_lex.h: Replace full_group_by_flag with two boolean flags, and itroduce accessors for manipulating them. sql/sql_select.cc: Use accessor functions for non_agg_field_used/agg_func_used.	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
Tor Didriksen	dd3d9477b2	Bug#11765713 58705: OPTIMIZER LET ENGINE DEPEND ON UNINITIALIZED VALUES CREATED BY OPT_SUM_QU Valgrind warnings were caused by comparing index values to an un-initialized field. mysql-test/r/subselect.result: New test cases. mysql-test/t/subselect.test: New test cases. sql/opt_sum.cc: Add thd to opt_sum_query enabling it to test for errors. If we have a non-nullable index, we cannot use it to match null values, since set_null() will be ignored, and we might compare uninitialized data. sql/sql_select.cc: Add thd to opt_sum_query, enabling it to test for errors. sql/sql_select.h: Add thd to opt_sum_query, enabling it to test for errors.	15 years ago

35 Commits (841a74a4d6ebdaa2760ce615e7fc18f57100ee19)