mariadb

Commit Graph

Author	SHA1	Message	Date
unknown	5fdb531d77	Fix bug MDEV-4895 Valgrind warnings (Conditional jump or move depends on uninitialised value) in Field_datetime::get_date on GREATEST(..) IS NULL Analysis: The cause of the valgrind warning was an attempt to evaluate a Field that was not yet read. The reason was that on one hand Item_func_isnotnull was marked as constant by Item_func_isnotnull::update_used_tables, and this allowed eval_const_cond() to be called. On the other hand Item_func_isnotnull::val_int() evaluated its argument as if it was not constant. Solution: The fix make sure that Item_func_isnotnull::val_int() doesn't evaluate its argument when it is constant and cannot be NULL, because the result is known in this case.	12 years ago
unknown	dafa458262	mysql-test/r/func_set.result:	12 years ago
Igor Babaev	fa7f677218	Fixed bug mdev-4355. This patch almost totally revised the patch for bug mdev-4177. The latter had too many defects. In particular, it did not propagate multiple equalities formed when merging a degenerate disjunct into underlying AND formula.	12 years ago
Alexander Barkov	e6a6f653a9	MDEV-4512 Valgrind warnings in my_long10_to_str_8bit on INTERVAL and DATE_ADD with incorrect types Fixing a typo: bit AND (&) was erroneously used instead of logical AND (&&)	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
unknown	8a23ae088d	MDEV-4647: Valgrind warnings (Conditional jump or move depends on uninitialised value) in Item_equal::fix_fields Fix to calm down valgrind.	12 years ago
Alexander Barkov	d98584f56a	Adding support for the SQL-standard temporal literals. added: mysql-test/r/temporal_literal.result mysql-test/t/temporal_literal.test modified: client/mysqlbinlog.cc include/my_time.h mysql-test/r/cast.result mysql-test/r/partition_innodb.result mysql-test/t/cast.test mysql-test/t/partition_innodb.test sql-common/my_time.c sql/field.cc sql/item.cc sql/item.h sql/item_cmpfunc.cc sql/item_create.cc sql/item_create.h sql/item_strfunc.cc sql/item_timefunc.cc sql/item_timefunc.h sql/sql_select.cc sql/sql_time.cc sql/sql_time.h sql/sql_yacc.yy storage/spider/spd_db_mysql.cc	12 years ago
Sergei Golubchik	78cc6db44a	MDEV-4667 DATE('string') incompability between mysql and mariadb Cleanup: remove TIME_FUZZY_DATE. Introduce TIME_FUZZY_DATES which means "very fuzzy, the resulting value is only used for comparison. It can be invalid date, fine, as long as it can be compared". Updated many tests results (they're better now).	12 years ago
Michael Widenius	5f1f2fc0e4	Applied all changes from Igor and Sanja	13 years ago
Chaithra Gopalareddy	0c903fb5c9	Bug#11766191:INVALID MEMORY READ IN DO_DIV_MOD WITH DOUBLY ASSIGNED VARIABLES Bug#12608543: CRASHES WITH DECIMALS AND STATEMENT NEEDS TO BE REPREPARED ERRORS Backporting these two fixes to 5.1 Added unittest to test my_decimal construtor and assignment operators sql/my_decimal.h: Added constructor and assignment operators for my_decimal unittest/my_decimal/my_decimal-t.cc: Added test to check constructor and assignment operators for my_decimal	13 years ago
Chaithra Gopalareddy	d0367abaff	Bug#11766191:INVALID MEMORY READ IN DO_DIV_MOD WITH DOUBLY ASSIGNED VARIABLES Bug#12608543: CRASHES WITH DECIMALS AND STATEMENT NEEDS TO BE REPREPARED ERRORS Backporting these two fixes to 5.1 Added unittest to test my_decimal construtor and assignment operators	13 years ago
unknown	9441e53653	MDEV-4345 Sampling of selectivity of LIKE predicate.	13 years ago
Michael Widenius	068c61978e	Temporary commit of 10.0-merge	13 years ago
Murthy Narkedimilli	8afe262ae5	Fix for Bug 16395495 - OLD FSF ADDRESS IN GPL HEADER	13 years ago
Murthy Narkedimilli	d978016d93	Fix for Bug 16395495 - OLD FSF ADDRESS IN GPL HEADER	13 years ago
Murthy Narkedimilli	fe85f54640	Bug 16395495 - OLD FSF ADDRESS IN GPL HEADER	13 years ago
Murthy Narkedimilli	d20a70fb55	Bug 16395495 - OLD FSF ADDRESS IN GPL HEADER	13 years ago
Sergei Golubchik	372bc22bfa	MDEV-4265 5.5 is slower than 5.3 because of many str_to_datetime calls get_datetime_value() should not double-cache its own Item_cache_temporal items, but it should cache other Item_cache items, such as Item_cache_str. sql/item.h: shortcut, to avoid going through the switch in Item::cmp_type() sql/item_cmpfunc.cc: even if the item is Item_cache_str - it still needs to be converted and cached. sql/item_timefunc.h: all descendants of Item_temporal_func always have cmp_type==TIME_RESULT. Even Item_date_add_interval, that might have field_type == MYSQL_TYPE_STRING.	13 years ago
Igor Babaev	fc1c8ffdad	The pilot patch for mwl#253.	13 years ago
Gleb Shchepa	f8cd565dd7	Bug #16311231 : MISSING DATA ON SUBQUERY WITH WHERE + XOR IN IN-CLAUSE USING MYISAM OR MEMORY ENGINE Backport from 5.6. Original message: The coincidences caused a data loss: * The query has IN subqueries nested twice, * the WHERE clause of the inner subquery refers to the outer field, and the whole WHERE clause returns FALSE, * the inner subquery has a LEFT JOIN that joins a single row with a row of NULLs; one of that NULL columns represents the select list of the subquery. Normally, that inner subquery should return empty record set. However, in our case: * the Item_is_not_null_test item goes constant, since its underlying field is NULL (because of LEFT JOIN ... ON FALSE of const table row with a row of nulls); * we evaluate Item_is_not_null_test::val_int() as a part of fake HAVING expression of the transformed subquery; * as far as the underlying field is NULL, we optimize out the whole fake HAVING expression as FALSE as well as a whole subquery with a zero result: Impossible HAVING noticed after reading const tables"; * thus, the optimizer ignores the presence of the WHERE clause (the WHERE expression is FALSE in our case, so the subquery should return empty set); * however, during the evaluation of the Item_is_not_null_test::val_int() in the optimizer, it marked its "owner" with the "was_null" flag -- that forced the subquery to return UNKNOWN instead of empty set. That caused a wrong result. The problem is a regression of the small cleanup in the fix for the bug11827369 (the Item_is_not_null_test part) that conflicts with optimizations in the fix for the bug11752543. Before that regression the Item_is_not_null_test items never were constants. The fix is the rollback of Item_is_not_null_test parts of the bug11827369 fix.	13 years ago
Gleb Shchepa	9e80a7891a	Bug #16311231 : MISSING DATA ON SUBQUERY WITH WHERE + XOR IN IN-CLAUSE USING MYISAM OR MEMORY ENGINE Backport from 5.6. Original message: The coincidences caused a data loss: * The query has IN subqueries nested twice, * the WHERE clause of the inner subquery refers to the outer field, and the whole WHERE clause returns FALSE, * the inner subquery has a LEFT JOIN that joins a single row with a row of NULLs; one of that NULL columns represents the select list of the subquery. Normally, that inner subquery should return empty record set. However, in our case: * the Item_is_not_null_test item goes constant, since its underlying field is NULL (because of LEFT JOIN ... ON FALSE of const table row with a row of nulls); * we evaluate Item_is_not_null_test::val_int() as a part of fake HAVING expression of the transformed subquery; * as far as the underlying field is NULL, we optimize out the whole fake HAVING expression as FALSE as well as a whole subquery with a zero result: Impossible HAVING noticed after reading const tables"; * thus, the optimizer ignores the presence of the WHERE clause (the WHERE expression is FALSE in our case, so the subquery should return empty set); * however, during the evaluation of the Item_is_not_null_test::val_int() in the optimizer, it marked its "owner" with the "was_null" flag -- that forced the subquery to return UNKNOWN instead of empty set. That caused a wrong result. The problem is a regression of the small cleanup in the fix for the bug11827369 (the Item_is_not_null_test part) that conflicts with optimizations in the fix for the bug11752543. Before that regression the Item_is_not_null_test items never were constants. The fix is the rollback of Item_is_not_null_test parts of the bug11827369 fix.	13 years ago
unknown	e3ac306157	[NOT] EXISTS to IN transformation.	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
Igor Babaev	ed7671d523	Fixed bug mdev-4172. This bug in the legacy code could manifest itself in queries with semi-join materialized subqueries. When a subquery is materialized all conditions that are imposed only on the columns belonging to the tables from the subquery are taken into account.The code responsible for subquery optimizations that employes subquery materialization makes sure to remove these conditions from the WHERE conditions of the query obtained after it has transformed the original query into a query with a semi-join. If the condition to be removed is an equality condition it could be added to ON expressions and/or conditions from disjunctive branches (parts of OR conditions) in an attempt to generate better access keys to the tables of the query. Such equalities are supposed to be removed later from all the formulas where they have been added to. However, erroneously, this was not done in some cases when an ON expression and/or a disjunctive part of the OR condition could be converted into one multiple equality. As a result some equality predicates over columns belonging to the tables of the materialized subquery remained in the ON condition and/or the a disjunctive part of the OR condition, and the excuter later, when trying to evaluate them, returned wrong answers as the values of the fields from these equalities were not valid. This happened because any standalone multiple equality (a multiple equality that are not ANDed with any other predicates) lacked the information about equality predicates inherited from upper levels (in particular, inherited from the WHERE condition). The fix adds a reference to such information to any standalone multiple equality.	13 years ago
Gleb Shchepa	19ea7c031d	Bug #11827369 : ASSERTION FAILED: !THD->LEX->CONTEXT_ANALYSIS_ONLY Some queries with the "SELECT ... FROM DUAL" nested subqueries failed with an assertion on debug builds. Non-debug builds were not affected. There were a few different issues with similar assertion failures on different queries: 1. The first problem was related to the incomplete propagation of the "non-constant" item status from underlying subquery items to the outer item tree: in some cases non-constants were interpreted as constants and evaluated at the preparation stage (val_int() calls withing fix_fields() etc). Thus, the default implementation of Item_ref::const_item() from the Item parent class didn't take into account the "const_item" status of the referenced item tree -- it used the insufficient "used_tables() == 0" check instead. This worked in most cases since our "non-constant" functions like RAND() and SLEEP() set the RAND_TABLE_BIT in the used table map, so they aren't non-constant from Item_ref's "point of view". However, the "SELECT ... FROM DUAL" subquery may have an empty map of used tables, but at the same time subqueries are never "constant" at the context analysis stage (preparation, view creation etc). So, the non-contantness of such subqueries was missed. Fix: the Item_ref::const_item() function has been overloaded to take into account both (ref)->const_item() status and tricky Item_ref::used_tables() return values, since the only (ref)->const_item() call is not enough there. 2. In some cases instead of the const_item() call we check a value of the Item::with_subselect field to recognize items with nested subqueries. However, the Item_ref class didn't propagate this value from the referenced item tree. Fix: Item::has_subquery() and Item_ref::has_subquery() functions have been backported from 5.6. All direct references to the with_subselect fields of nested items have been with the has_subquery() function call. 3. The Item_func_regex class didn't propagate with_subselect as well, since it overloads the Item_func::fix_fields() function with insufficient fix_fields() implementation. Fix: the Item_func_regex::fix_fields() function has been modified to gather "constant" statuses from inner items. 4. The Item_func_isnull::update_used_tables() function has a special branch for the underlying item where the maybe_null value is false: in this case it marks the Item_func_isnull as a "const_item" and sets the cached_value to false. However, the Item_func_isnull::val_int() was not in sync with update_used_tables(): it didn't take into account neither const_item_cache nor cached_value for the case of "args[0]->maybe_null == false optimization". As far as such an Item_func_isnull has "const_item() == true", it's ok to call Item_func_isnull::val_int() etc from outer items on preparation stage. In this case the server tried to call Item_func_isnull::args[0]->isnull(), and if the args[0] item contained a nested not-nullable subquery, it failed with an assertion. Fix: take the value of Item_func_isnull::const_item_cache into account in the val_int() function. 5. The auxiliary Item_is_not_null_test class has a similar optimization in the update_used_tables() function as the Item_func_isnull class has, and the same issue in the val_int() function. In addition to that the Item_is_not_null_test::update_used_tables() doesn't update the const_item_cache value, so the "maybe_null" optimization is useless there. Thus, we missed some optimizations of cases like these (before and after the fix): < <is_not_null_test>(a), --- > <cache>(<is_not_null_test>(a)), or < having (<is_not_null_test>(a) and <is_not_null_test>(a)) --- > having 1 etc. Fix: update Item_is_not_null_test::const_item_cache in update_used_tables() and take in into account in val_int().	13 years ago
Gleb Shchepa	e53345f04b	Bug #11827369 : ASSERTION FAILED: !THD->LEX->CONTEXT_ANALYSIS_ONLY Some queries with the "SELECT ... FROM DUAL" nested subqueries failed with an assertion on debug builds. Non-debug builds were not affected. There were a few different issues with similar assertion failures on different queries: 1. The first problem was related to the incomplete propagation of the "non-constant" item status from underlying subquery items to the outer item tree: in some cases non-constants were interpreted as constants and evaluated at the preparation stage (val_int() calls withing fix_fields() etc). Thus, the default implementation of Item_ref::const_item() from the Item parent class didn't take into account the "const_item" status of the referenced item tree -- it used the insufficient "used_tables() == 0" check instead. This worked in most cases since our "non-constant" functions like RAND() and SLEEP() set the RAND_TABLE_BIT in the used table map, so they aren't non-constant from Item_ref's "point of view". However, the "SELECT ... FROM DUAL" subquery may have an empty map of used tables, but at the same time subqueries are never "constant" at the context analysis stage (preparation, view creation etc). So, the non-contantness of such subqueries was missed. Fix: the Item_ref::const_item() function has been overloaded to take into account both (ref)->const_item() status and tricky Item_ref::used_tables() return values, since the only (ref)->const_item() call is not enough there. 2. In some cases instead of the const_item() call we check a value of the Item::with_subselect field to recognize items with nested subqueries. However, the Item_ref class didn't propagate this value from the referenced item tree. Fix: Item::has_subquery() and Item_ref::has_subquery() functions have been backported from 5.6. All direct references to the with_subselect fields of nested items have been with the has_subquery() function call. 3. The Item_func_regex class didn't propagate with_subselect as well, since it overloads the Item_func::fix_fields() function with insufficient fix_fields() implementation. Fix: the Item_func_regex::fix_fields() function has been modified to gather "constant" statuses from inner items. 4. The Item_func_isnull::update_used_tables() function has a special branch for the underlying item where the maybe_null value is false: in this case it marks the Item_func_isnull as a "const_item" and sets the cached_value to false. However, the Item_func_isnull::val_int() was not in sync with update_used_tables(): it didn't take into account neither const_item_cache nor cached_value for the case of "args[0]->maybe_null == false optimization". As far as such an Item_func_isnull has "const_item() == true", it's ok to call Item_func_isnull::val_int() etc from outer items on preparation stage. In this case the server tried to call Item_func_isnull::args[0]->isnull(), and if the args[0] item contained a nested not-nullable subquery, it failed with an assertion. Fix: take the value of Item_func_isnull::const_item_cache into account in the val_int() function. 5. The auxiliary Item_is_not_null_test class has a similar optimization in the update_used_tables() function as the Item_func_isnull class has, and the same issue in the val_int() function. In addition to that the Item_is_not_null_test::update_used_tables() doesn't update the const_item_cache value, so the "maybe_null" optimization is useless there. Thus, we missed some optimizations of cases like these (before and after the fix): < <is_not_null_test>(a), --- > <cache>(<is_not_null_test>(a)), or < having (<is_not_null_test>(a) and <is_not_null_test>(a)) --- > having 1 etc. Fix: update Item_is_not_null_test::const_item_cache in update_used_tables() and take in into account in val_int().	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	40ae63dd65	backport to 5.5 dyncol changes and names support	13 years ago
Roy Lyseng	96c373c51a	Bug#15972635: Incorrect results returned in 32 table join with HAVING The problem is a shift operation that is not 64-bit safe. The consequence is that used tables information for a join with 32 tables or more will be incorrect. Fixed by adding a type cast in Item_sum::update_used_tables(). Also used the opportunity to fix some other potential bugs by adding an explicit type-cast to an integer in a left-shift operation. Some of them were quite harmless, but was fixed in order to get the same signed-ness as the other operand of the operation it was used in. sql/item_cmpfunc.cc Adjusted signed-ness for some integers in left-shift. sql/item_subselect.cc Added type-cast to nesting_map (which is a 32/64 bit type, so potential bug for deeply nested queries). sql/item_sum.cc Added type-cast to nesting_map (32/64-bit type) and table_map (64-bit type). sql/opt_range.cc Added type-cast to ulonglong (which is a 64-bit type). sql/sql_base.cc Added type-cast to nesting_map (which is a 32/64-bit type). sql/sql_select.cc Added type-cast to nesting_map (32/64-bit type) and key_part_map (64-bit type). sql/strfunc.cc Changed type-cast from longlong to ulonglong, to preserve signed-ness.	13 years ago
Roy Lyseng	8b1d1cf5c0	Bug#15972635: Incorrect results returned in 32 table join with HAVING The problem is a shift operation that is not 64-bit safe. The consequence is that used tables information for a join with 32 tables or more will be incorrect. Fixed by adding a type cast in Item_sum::update_used_tables(). Also used the opportunity to fix some other potential bugs by adding an explicit type-cast to an integer in a left-shift operation. Some of them were quite harmless, but was fixed in order to get the same signed-ness as the other operand of the operation it was used in. sql/item_cmpfunc.cc Adjusted signed-ness for some integers in left-shift. sql/item_subselect.cc Added type-cast to nesting_map (which is a 32/64 bit type, so potential bug for deeply nested queries). sql/item_sum.cc Added type-cast to nesting_map (32/64-bit type) and table_map (64-bit type). sql/opt_range.cc Added type-cast to ulonglong (which is a 64-bit type). sql/sql_base.cc Added type-cast to nesting_map (which is a 32/64-bit type). sql/sql_select.cc Added type-cast to nesting_map (32/64-bit type) and key_part_map (64-bit type). sql/strfunc.cc Changed type-cast from longlong to ulonglong, to preserve signed-ness.	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	7327cd9717	MDEV-377 Name support for dynamic columns MDEV-127 Optimization of memory allocation MDEV-483 Make column_check function which cheсks dynamic columns integrit JSON conversion function	13 years ago
Tor Didriksen	b079b388a5	Backport Bug #11764313 57135: CRASH IN ITEM_FUNC_CASE::FIND_ITEM WITH CASE WHEN Bug #11764818 57692: Crash in item_func_in::val_int() with ZEROFILL	13 years ago
Tor Didriksen	abdb79062e	Backport Bug #11764313 57135: CRASH IN ITEM_FUNC_CASE::FIND_ITEM WITH CASE WHEN Bug #11764818 57692: Crash in item_func_in::val_int() with ZEROFILL	13 years ago
unknown	60561ae613	Fix for LP bug#1001505 and LP bug#1001510 We set correct cmp_context during preparation to avoid changing it later by Item_field::equal_fields_propagator. (see mysql bugs #57135 #57692 during merging)	14 years ago
Sergei Golubchik	a247b12fe6	MDEV-316 lp:1009085 Assertion failed: warn_item, file item_cmpfunc.cc, line 3613 make sure that find_date_time_item() is called before agg_arg_charsets_for_comparison(). optimize Item_func_conv_charset to avoid conversion if no string result is needed	14 years ago
unknown	66dfceb11f	Fix for bug lp:1006231 Analysis: When a subquery that needs a temp table is executed during the prepare or optimize phase of the outer query, at the end of the subquery execution all the JOIN_TABs of the subquery are replaced by a new JOIN_TAB that selects from the temp table. However that temp table has no corresponding TABLE_LIST. Once EXPLAIN execution reaches its last phase, it tries to print the names of the subquery tables through its TABLE_LISTs, but in the case of this bug there is no such TABLE_LIST (it is NULL), hence a crash. Solution: The fix is to block subquery evaluation inside Item_func_like::fix_fields and Item_func_like::select_optimize() using the Item::is_expensive() test.	14 years ago
unknown	f45784c850	Fix of LP bug#992380 + revise fix_fields about missing with_subselect collection The problem is that some fix_fields do not call Item_func::fix_fields and do not collect with subselect_information.	14 years ago
unknown	4fa89b5fe0	Test case for bug lp:1001117, MySQL BUG#12330344 Analysis: The problem in the original MySQL bug is that the range optimizer performs its analysis in a separate MEM_ROOT object that is freed after the range optimzier is done. During range analysis get_mm_tree calls Item_func_like::select_optimize, which in turn evaluates its right argument. In the test case the right argument is a subquery. In MySQL, subqueries are optimized lazyly, thus the call to val_str triggers optimization for the subquery. All objects needed by the subquery plan end up in the temporary MEM_ROOT used by the range optimizer. When execution ends, the JOIN::cleanup process tries to cleanup objects of the subquery plan, but all these objects are gone with the temporary MEM_ROOT. The solution for MySQL is to switch the mem_root. In MariaDB with the patch for bug lp:944706, all constant subqueries that may be used by the optimization process are preoptimized. Therefore Item_func_like::select_optimize only triggers subquery execution, and the above problem is not present. The patch however adds a test whether the evaluated right argument of the LIKE predicate is expensive. This is consistent with our approach not to evaluate expensive expressions during optimization.	14 years ago
unknown	950abd5268	Fix of LP bug#992380 + revise fix_fields about missing with_subselect collection The problem is that some fix_fields do not call Item_func::fix_fields and do not collect with subselect_information.	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
unknown	5a47413934	fix of LP bug#998321 The problem is that we can't check null_value field of non-basic constant without the item execution.:	14 years ago
Mayank Prasad	0581d1c46c	Bug#11766101 : 59140: LIKE CONCAT('%',@A,'%') DOESN'T MATCH WHEN @A CONTAINS LATIN1 STRING Issue/Cause: Issue is of memory corruption.During optimization phase, pattern to be matched in where clause, is prepared. This is done in Item_func_concat::val_str() function which forms the resultant string (tmp_value) and return its pointer. In caller, Item_func_like::fix_fields, pattern is made to point to this string (tmp_value). In further processing, tmp_value is getting modified which causes pattern to have changed/wrong values. Fix: Allocate its own memroy location in caller, copy value of resultant string (tmp_value) into that and make pattern to point to that. This makes sure no further changes to tmp_value will affect pattern.	14 years ago
Mayank Prasad	5fb35050c7	Bug#11766101 : 59140: LIKE CONCAT('%',@A,'%') DOESN'T MATCH WHEN @A CONTAINS LATIN1 STRING Issue/Cause: Issue is of memory corruption.During optimization phase, pattern to be matched in where clause, is prepared. This is done in Item_func_concat::val_str() function which forms the resultant string (tmp_value) and return its pointer. In caller, Item_func_like::fix_fields, pattern is made to point to this string (tmp_value). In further processing, tmp_value is getting modified which causes pattern to have changed/wrong values. Fix: Allocate its own memroy location in caller, copy value of resultant string (tmp_value) into that and make pattern to point to that. This makes sure no further changes to tmp_value will affect pattern.	14 years ago
Sergey Petrunya	e2554b50cd	BUG#951937: Wrong result (missing rows) with semijoin+materialization, IN subquery, InnoDB, TEMPTABLE view - Fix equality propagation to work with SJM nests and OR clauses (full descirption of problem and solution in the comment in the patch) (The second commit with post-review fixes)	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	53fde5bb6f	BUG#922254: Assertion `0' failed at item_cmpfunc.cc:5899: Item* Item_equal::get_first(JOIN_TAB, Item) Fixed Item* Item_equal::get_first(JOIN_TAB context, Item field_item) to work correctly in the case where: - context!= NO_PARTICULAR_TAB, it points to a table within SJ-Materialization nest - field_item points to an item_equal that has a constant Item_field but does not have any fields from tables that are within semi-join nests.	14 years ago
Tor Didriksen	042bd1511d	Bug#13463415 63502: INCORRECT RESULTS OF BIGINT AND DECIMAL COMPARISON Bug#11758543 50756: BIGINT '100' MATCHES 1.001E2 Expressions of the form BIGINT_COL <compare> <non-integer constant> should be done either as decimal, or float. Currently however, such comparisons are done as int, which means that the constant may be truncated, and yield false positives/negatives for all queries where compare is '>' '<' '>=' '<=' '=' '!='. BIGINT_COL IN <list of contstants> and BIGINT_COL BETWEEN <constant> AND <constant> are also affected. mysql-test/r/bigint.result: New tests. mysql-test/r/func_in.result: BIGINT <=> string comparison should be done as float, so a warning for the value 'abc' is appropriate. mysql-test/t/bigint.test: New tests. sql/item_cmpfunc.cc: In convert_constant_item() we verify that the constant item can be stored in the given field. For BIGINT columns (MYSQL_TYPE_LONGLONG) we must verify that the stored constant value is actually comparable as int, i.e. that the value was not truncated. For between: compare as int only if both arguments convert correctly to int.	14 years ago
Tor Didriksen	07fd88d567	Bug#13463415 63502: INCORRECT RESULTS OF BIGINT AND DECIMAL COMPARISON Bug#11758543 50756: BIGINT '100' MATCHES 1.001E2 Expressions of the form BIGINT_COL <compare> <non-integer constant> should be done either as decimal, or float. Currently however, such comparisons are done as int, which means that the constant may be truncated, and yield false positives/negatives for all queries where compare is '>' '<' '>=' '<=' '=' '!='. BIGINT_COL IN <list of contstants> and BIGINT_COL BETWEEN <constant> AND <constant> are also affected.	14 years ago
Sergey Petrunya	9f60aa27f7	BUG#912513: Wrong result (missing rows) with join_cache_hashed+materialization+semijoin=on - equality substitution code was geared towards processing WHERE/ON clauses. that is, it assumed that it was doing substitions on the code that = wasn't attached to any particular join_tab yet = was going to be fed to make_join_select() which would take the condition apart and attach various parts of it to tables inside/outside semi-joins. - However, somebody added equality substition for ref access. That is, if we have a ref access on TBL.key=expr, they would do equality substition in 'expr'. This possibility wasn't accounted for. - Fixed equality substition code by adding a mode that does equality substition under assumption that the processed expression will be attached to a certain particular table TBL.	14 years ago

1 2 3 4 5 ...

2085 Commits (d833bb65d53b9a4375fa71cc485b4719fdb0ee53)