- 25 Aug, 2006 3 commits
-
-
unknown authored
into mysql.com:/home/psergey/mysql-5.0-bug16255-merge
-
unknown authored
into rurik.mysql.com:/home/igor/mysql-5.0-opt
-
unknown authored
const tables. This resulted in choosing extremely inefficient execution plans in same cases when distribution of data in joined were skewed (see the customer test case for the bug). mysql-test/r/select.result: Added a test case for bug #21390: wrong estimate of rows after elimination of const tables. Includded a test case that checks the code added by the patch that handles outer joins with no matches after substitution of a const table in an efficient way. mysql-test/t/select.test: Added a test case for bug #21390: wrong estimate of rows after elimination of const tables. Included a test case that checks the code added by the patch that handles outer joins with no matches after substitution of a const table in an efficient way. sql/sql_select.cc: Fixed bug #21390: wrong estimate of rows after elimination of const tables. This resulted in choosing extremely inefficient execution plans in same cases when distribution of data in joined were skewed (see the customer test case for the bug). Also added the code to handle outer joins with no matches after substitution of a const table in an efficient way. Corrected calculation of the null rejecting key conditions.
-
- 24 Aug, 2006 5 commits
-
-
unknown authored
Corrected fix for bug#18165 sql/opt_range.cc: Corrected fix for bug#18165
-
unknown authored
Corrected fix for bug#18165 sql/opt_range.cc: Corrected fix for bug#18165
-
unknown authored
-
unknown authored
mysql-test/r/subselect.result: BUG#16255: A proper testcase mysql-test/t/subselect.test: BUG#16255: A proper testcase
-
unknown authored
Must not use Item_direct_ref in HAVING because it points to the new value (witch is not yet calculated for the first row). mysql-test/r/subselect.result: Bug #16255: Subquery in where - test case mysql-test/t/subselect.test: Bug #16255: Subquery in where - test case sql/item_subselect.cc: Bug #16255: Subquery in where Must not use Item_direct_ref in HAVING because it points to the new value (witch is not yet calculated for the first row).
-
- 23 Aug, 2006 1 commit
-
-
unknown authored
Corrected test case for the bug#21261 sql_parse.cc: Corrected fix for bug#21261 mysql-test/t/view.test: Corrected test case for the bug#21261 mysql-test/r/view.result: Corrected test case for the bug#21261 sql/sql_parse.cc: Corrected fix for bug#21261
-
- 22 Aug, 2006 8 commits
-
-
unknown authored
into moonbone.local:/work/21475-fix-5.0-opt-mysql
-
unknown authored
Additional fix for bug #21475 item_func.h, item_func.cc: Additional fix for bug#16861 sql/item_func.h: Additional fix for bug#16861 sql/item_func.cc: Additional fix for bug#16861 sql/item_cmpfunc.cc: Additional fix for bug #21475 sql/item.cc: Additional fix for bug #21475
-
unknown authored
into rurik.mysql.com:/home/igor/mysql-5.0-opt
-
unknown authored
into sunlight.local:/local_work/16861-bug-5.0-mysql sql/sql_select.cc: Auto merged
-
unknown authored
used. Sorting by RAND() uses a temporary table in order to get a correct results. User defined variable was set during filling the temporary table and later on it is substituted for its value from the temporary table. Due to this it contains the last value stored in the temporary table. Now if the result_field is set for the Item_func_set_user_var object it updates variable from the result_field value when being sent to a client. The Item_func_set_user_var::check() now accepts a use_result_field parameter. Depending on its value the result_field or the args[0] is used to get current value. mysql-test/r/user_var.result: Added a test case for bug#16861: User defined variable can have a wrong value if a tmp table was used. mysql-test/t/user_var.test: Added a test case for bug#16861: User defined variable can have a wrong value if a tmp table was used. sql/item_func.cc: Fixed bug#16861: User defined variable can have a wrong value if a tmp table was used. Now if the result_field is set for the Item_func_set_user_var object it updates variable from the result_field value when being sent to a client. The Item_func_set_user_var::check() now accepts a use_result_field parameter. Depending on its value the result_field or the args[0] is used to get current value. sql/item_func.h: Fixed bug#16861: User defined variable can have a wrong value if a tmp table was used. Added a new SUSERVAR_FUNC function type. Updated the Item_func_set_user_var::check() function declaration. Added the Item_func_set_user_var::send() member function. sql/set_var.cc: Fixed bug#16861: User defined variable can have a wrong value if a tmp table was used. Modified to use updated Item_func_set_user_var::check() function. sql/sql_class.cc: Fixed bug#16861: User defined variable can have a wrong value if a tmp table was used. Modified to use updated Item_func_set_user_var::check() function. sql/sql_select.cc: Fixed bug#16861: User defined variable can have a wrong value if a tmp table was used. Now an Item_func_set_user_var object isn't substituted for an Item_field object after filling a temporary table.
-
unknown authored
into moonbone.local:/work/21475-bug-5.0-opt-mysql
-
unknown authored
buffer for a MY_BITMAP temporary buffer allocated on stack in the function get_best_covering_ror_intersect(). Now the buffer of a proper size is allocated by a request from this function in mem_root. We succeeded to demonstrate the bug only on Windows with a very large database. That's why no test case is provided for in the patch. sql/opt_range.cc: Fixed bug 16201: a memory corruption causing crashes due to a too small buffer for a MY_BITMAP temporary buffer allocated on stack in the function get_best_covering_ror_intersect(). Now the buffer of a proper size is allocated by a request from this function in mem_root.
-
unknown authored
-
- 21 Aug, 2006 2 commits
-
-
unknown authored
-
unknown authored
Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0 - moved an InnoDB dependent test to the appropriate file mysql-test/r/innodb_mysql.result: Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0 - moved an InnoDB dependent test to the appropriate file mysql-test/r/join_outer.result: Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0 - moved an InnoDB dependent test to the appropriate file mysql-test/t/innodb_mysql.test: Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0 - moved an InnoDB dependent test to the appropriate file mysql-test/t/join_outer.test: Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0 - moved an InnoDB dependent test to the appropriate file
-
- 20 Aug, 2006 1 commit
-
-
unknown authored
A date can be represented as an int (like 20060101) and as a string (like "2006.01.01"). When a DATE/TIME field is compared in one SELECT against both representations the constant propagation mechanism leads to comparison of DATE as a string and DATE as an int. In this example it compares 2006 and 20060101 integers. Obviously it fails comparison although they represents the same date. Now the Item_bool_func2::fix_length_and_dec() function sets the comparison context for items being compared. I.e. if items compared as strings the comparison context is STRING. The constant propagation mechanism now doesn't mix items used in different comparison contexts. The context check is done in the Item_field::equal_fields_propagator() and in the change_cond_ref_to_const() functions. Also the better fix for bug 21159 is introduced. mysql-test/t/type_datetime.test: Added a test case for bug#21475: Wrongly applied constant propagation leads to a false comparison. mysql-test/r/type_datetime.result: Added a test case for bug#21475: Wrongly applied constant propagation leads to a false comparison. sql/sql_select.cc: Fixed bug#21475: Wrongly applied constant propagation leads to a false comparison. The constant propagation mechanism now doesn't mix items used in different comparison contexts. The check is done in the change_cond_ref_to_const() function. sql/item_cmpfunc.cc: Fixed bug#21475: Wrongly applied constant propagation leads to a false comparison. Now the Item_bool_func2::fix_length_and_dec() function sets the comparison context for items being compared. sql/item.h: Fixed bug#21475: Wrongly applied constant propagation leads to a false comparison. To the Item class a new field called cmp_context is added. It represents the comparison context of an item. sql/item.cc: Fixed bug#21475: Wrongly applied constant propagation leads to a false comparison. The constant propagation mechanism now doesn't mix items used in different comparison contexts. The context check is done in the Item_field::equal_fields_propagator() function.
-
- 17 Aug, 2006 1 commit
-
-
unknown authored
Corrected test case result after fix for bug#18165 view.result, view.test: Corrected test case for bug#21261 mysql-test/t/view.test: Corrected test case for bug#21261 mysql-test/r/view.result: Corrected test case for bug#21261 mysql-test/r/ndb_condition_pushdown.result: Corrected test case result after fix for bug#18165
-
- 16 Aug, 2006 3 commits
-
-
unknown authored
into rurik.mysql.com:/home/igor/mysql-5.0-opt sql/sql_select.cc: Auto merged
-
unknown authored
Made [NOT]BETWEEN predicates SARGable in respect to the second and the third arguments. mysql-test/r/range.result: Added a test case to bug #18165. mysql-test/t/range.test: Added a test case to bug #18165. sql/opt_range.cc: Fixed bug #18165. Made [NOT]BETWEEN predicates SARGable in respect to the second and the third arguments. Put in a separate function called get_full_func_mm_tree the functionality that builds a conjunction of all SEL_TREEs for a simple predicate of the form (f op c), where f was a field and c was a constant, applying different equalities f=f' with f' being another field.
-
unknown authored
into sunlight.local:/local_work/21261-bug-5.0-mysql sql/sql_select.cc: Auto merged sql/sql_update.cc: Auto merged mysql-test/r/view.result: SCCS merged mysql-test/t/view.test: SCCS merged
-
- 15 Aug, 2006 13 commits
-
-
unknown authored
into moonbone.local:/work/15950-bug-5.0-opt-mysql
-
unknown authored
SELECT right instead of INSERT right was required for an insert into to a view. This wrong behaviour appeared after the fix for bug #20989. Its intention was to ask only SELECT right for all tables except the very first for a complex INSERT query. But that patch has done it in a wrong way and lead to asking a wrong access right for an insert into a view. The setup_tables_and_check_access() function now accepts two want_access parameters. One will be used for the first table and the second for other tables. mysql-test/t/view.test: Added a test case for bug#21261: Wrong access rights was required for an insert into a view mysql-test/r/view.result: Added a test case for bug#21261: Wrong access rights was required for an insert into a view sql/sql_update.cc: Fixed bug#21261: Wrong access rights was required for an insert into a view Modified to use updated setup_tables_and_check_access() function. sql/sql_select.cc: Fixed bug#21261: Wrong access rights was required for an insert into a view Modified to use updated setup_tables_and_check_access() function. sql/sql_load.cc: Fixed bug#21261: Wrong access rights was required for an insert into a view Modified to use updated setup_tables_and_check_access() function. sql/sql_insert.cc: Fixed bug#21261: Wrong access rights was required for an insert into a view Modified to use updated setup_tables_and_check_access() function. sql/sql_delete.cc: Fixed bug#21261: Wrong access rights was required for an insert into a view Modified to use updated setup_tables_and_check_access() function. sql/sql_base.cc: Fixed bug#21261: Wrong access rights was required for an insert into a view The setup_tables_and_check_access() function now accepts two want_access parameters. One will be used for the first table and the second for other tables. sql/mysql_priv.h: Fixed bug#21261: Wrong access rights was required for an insert into a view The setup_tables_and_check_access() function now accepts two want_access parameters.
-
unknown authored
into mysql.com:/home/psergey/mysql-5.0-opt-bug21282-r2
-
unknown authored
-
unknown authored
In fix for BUG#15872, a condition of type "t.key NOT IN (c1, .... cN)" where N>1000, was incorrectly converted to (-inf < X < c_min) OR (c_max < X) Now this conversion is removed, we dont produce any range lists for such conditions. mysql-test/r/range.result: BUG#21282: Testcase mysql-test/t/range.test: BUG#21282: Testcase sql/opt_range.cc: BUG#21282: Incorrect query results for "t.key NOT IN (<big const list>) In fix for BUG#15872, a condition of type "t.key NOT IN (c1, .... cN)" where N>1000, was incorrectly converted to (-inf < X < c_min) OR (c_max < X) Now this conversion is removed, we dont produce any range lists for such conditions.
-
unknown authored
This bug is a side-effect of bug fix #16377. NOW() is optimized in BETWEEN to integer constants to speed up query execution. When view is being created it saves already modified query and thus becomes wrong. The agg_cmp_type() function now substitutes constant result DATE/TIME functions for their results only if the current query isn't CREATE VIEW or SHOW CREATE VIEW. mysql-test/t/view.test: Added a test case for bug#15950: NOW() optimized away in VIEWs mysql-test/r/view.result: Added a test case for bug#15950: NOW() optimized away in VIEWs sql/item_cmpfunc.cc: Fixed bug#15950: NOW() optimized away in VIEWs The agg_cmp_type() function now substitutes constant result DATE/TIME functions for their results only if the current query isn't CREATE VIEW or SHOW CREATE VIEW.
-
unknown authored
BUG#21077: Possible crash caused by invalid sequence of handler::* calls: The crash was caused by invalid sequence of handler::** calls: ha_smth->index_init(); ha_smth->index_next_same(); (2) (2) is an invalid call as it was not preceeded by any 'scan setup' call like index_first() or index_read(). The cause was that QUICK_SELECT::reset() didn't "fully reset" the quick select- current QUICK_RANGE wasn't forgotten, and quick select might attempt to continue reading the range, which would result in the above mentioned invalid sequence of handler calls. 5.x versions are not affected by the bug - they already have the missing "range=NULL" clause. mysql-test/r/innodb_mysql.result: Testcase for BUG#21077 mysql-test/t/innodb_mysql.test: Testcase for BUG#21077 sql/opt_range.h: BUG#21077: Possible crash caused by invalid sequence of handler::* calls: - Make QUICK_SELECT::reset() really reset the quick select
-
unknown authored
- undeterminstic tests fixed mysql-test/r/order_by.result: Bug #21302: Result not properly sorted when using an ORDER BY on a second table in a join - more undeterminstic tests fixed mysql-test/t/order_by.test: Bug #21302: Result not properly sorted when using an ORDER BY on a second table in a join - more undeterminstic tests fixed
-
unknown authored
on a second table in a join - undeterministic output of the test case removed.
-
unknown authored
into rakia.(none):/home/kgeorge/mysql/autopush/B21159-5.0-opt sql/sql_select.cc: Auto merged
-
unknown authored
into rakia.(none):/home/kgeorge/mysql/autopush/B21174-5.0-opt sql/sql_select.cc: Auto merged
-
unknown authored
into rakia.(none):/home/kgeorge/mysql/autopush/B21159-5.0-opt sql/sql_select.cc: Auto merged
-
unknown authored
Disable const propagation for Item_hex_string. This must be done because Item_hex_string->val_int() is not the same as (Item_hex_string->val_str() in BINARY column)->val_int(). We cannot simply disable the replacement in a particular context ( e.g. <bin_col> = <int_col> AND <bin_col> = <hex_string>) since Items don't know the context they are in and there are functions like IF (<hex_string>, 'yes', 'no'). Note that this will disable some valid cases as well (e.g. : <bin_col> = <hex_string> AND <bin_col2> = <bin_col>) but there's no way to distinguish the valid cases without having the Item's parent say something like : Item->set_context(Item::STRING_RESULT) and have all the Items that contain other Items do that consistently. mysql-test/r/compare.result: Bug #21159: Optimizer: wrong result after AND with different data types - test case mysql-test/t/compare.test: Bug #21159: Optimizer: wrong result after AND with different data types - test case sql/sql_select.cc: Bug #21159: Optimizer: wrong result after AND with different data types - disable const propagation for Item_hex_string.
-
- 14 Aug, 2006 3 commits
-
-
unknown authored
optimizer does not honor IGNORE INDEX - Allow an index to be used for sorting the table instead of filesort only if it is not disabled by IGNORE INDEX. mysql-test/r/group_by.result: Bug #21174: Index degrades sort performance and optimizer does not honor IGNORE INDEX - test case mysql-test/t/group_by.test: Bug #21174: Index degrades sort performance and optimizer does not honor IGNORE INDEX - test case
-
unknown authored
into rakia.(none):/home/kgeorge/mysql/autopush/B21302-5.0-opt mysql-test/r/join_outer.result: Auto merged mysql-test/r/order_by.result: Auto merged
-
unknown authored
table in a join The optimizer removes redundant columns in ORDER BY. It is considering redundant every reference to const table column, e.g b in : create table t1 (a int, b int, primary key(a)); select 1 from t1 order by b where a = 1 But it must not remove references to const table columns if the const table is an outer table because there still can be 2 values : the const value and NULL. e.g.: create table t1 (a int, b int, primary key(a)); select t2.b c from t1 left join t1 t2 on (t1.a = t2.a and t2.a = 5) order by c; mysql-test/r/join_outer.result: Bug #21302: Result not properly sorted when using an ORDER BY on a second table in a join - don't remove columns of const tables in ORDER BY if the const table is an outer table. mysql-test/r/order_by.result: Bug #21302: Result not properly sorted when using an ORDER BY on a second table in a join - test case mysql-test/t/order_by.test: Bug #21302: Result not properly sorted when using an ORDER BY on a second table in a join - test case sql/sql_select.cc: Bug #21302: Result not properly sorted when using an ORDER BY on a second table in a join - don't remove columns of const tables in ORDER BY if the const table is an outer table.
-