The bug was as follows: When merge_key_fields() encounters "t.key=X OR t.key=Y" it will
try to join them into ref_or_null access via "t.key=X OR NULL". In order to make this
inference it checks if Y<=>NULL, ignoring the fact that value of Y may be not yet known.
The fix is that the check if Y<=>NULL is made only if value of Y is known (i.e. it is a
constant).
TODO: When merging to 5.0, replace used_tables() with const_item() everywhere in merge_key_fields().
mysql-test/r/innodb_mysql.result:
Testcase for BUG16798
mysql-test/t/innodb_mysql.test:
Testcase for BUG16798
sql/sql_select.cc:
BUG#16798: Inapplicable ref_or_null query plan and bad query result on random occasions
In merge_key_fields() don't call val->is_null() if the value of val is not known.
The bug was as follows: When merge_key_fields() encounters "t.key=X OR t.key=Y" it will
try to join them into ref_or_null access via "t.key=X OR NULL". In order to make this
inference it checks if Y<=>NULL, ignoring the fact that value of Y may be not yet known.
The fix is that the check if Y<=>NULL is made only if value of Y is known (i.e. it is a
constant).
TODO: When merging to 5.0, replace used_tables() with const_item() everywhere in merge_key_fields().
into mysql.com:/home/my/mysql-5.1
mysql-test/lib/mtr_report.pl:
Auto merged
mysql-test/mysql-test-run.sh:
Auto merged
mysql-test/r/subselect.result:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_test.cc:
Auto merged
sql/sql_view.cc:
Auto merged
sql/sql_lex.cc:
manual merge
into rurik.mysql.com:/home/igor/dev/mysql-5.0-0
mysql-test/r/subselect.result:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/sql_select.cc:
Auto merged
This performance degradation was due to the fact that some
cost evaluation code added into 4.1 in the function find_best was
not merged into the code of the function best_access_path added
together with other code for greedy optimizer.
Added a parameter to the function print_plan. The parameter contains
accumulated cost for a given partial join.
The patch does not include a special test case since this performance
degradation is hard to reproduse with a simple example.
TODO: make the function find_best use the function best_access_path
in order to remove duplication of code which might result in incomplete
merges in the future.
mysql-test/r/delete.result:
Fixed bug #14292: performance degradation for a benchmark query.
Adjusted test results.
mysql-test/r/subselect.result:
Fixed bug #14292: performance degradation for a benchmark query.
Adjusted test results.
sql/mysql_priv.h:
Fixed bug #14292: performance degradation for a benchmark query.
Added a parameter to the function print_plan. The parameter contains
accumulated cost for a given partial join.
sql/sql_select.cc:
Fixed bug #14292: performance degradation for a benchmark query.
This performance degradation was due to the fact that some
cost evaluation code added into 4.1 in the function find_best was
not merged into the code of the function best_access_path added
together with other code for greedy optimizer.
sql/sql_test.cc:
Fixed bug #14292: performance degradation for a benchmark query.
Added a parameter to the function print_plan. The parameter contains
accumulated cost for a given partial join.
This performance degradation was due to the fact that some
cost evaluation code added into 4.1 in the function find_best was
not merged into the code of the function best_access_path added
together with other code for greedy optimizer.
Added a parameter to the function print_plan. The parameter contains
accumulated cost for a given partial join.
The patch does not include a special test case since this performance
degradation is hard to reproduse with a simple example.
TODO: make the function find_best use the function best_access_path
in order to remove duplication of code which might result in incomplete
merges in the future.
into mysql.com:/home/jimw/my/mysql-5.1-clean
mysql-test/r/user_var.result:
Auto merged
mysql-test/r/variables.result:
Auto merged
mysql-test/t/variables.test:
Auto merged
sql/item.cc:
Auto merged
sql/item_func.cc:
Auto merged
sql/sql_select.cc:
Auto merged
mysql-test/mysql-test-run.pl:
Resolve conflict
mysql-test/ndb/ndbcluster.sh:
Resolve conflict
sql/set_var.cc:
Resolve conflict
sql/share/errmsg.txt:
Resolve conflict
client/mysql.cc:
Auto merged
mysql-test/mysql-test-run.sh:
Auto merged
mysql-test/r/func_gconcat.result:
Auto merged
mysql-test/t/rpl_relayrotate.test:
Auto merged
mysys/mf_keycache.c:
Auto merged
BitKeeper/deleted/.del-innodb_unsafe_binlog-master.opt~9cbe1bb3d8696c5b:
Auto merged
mysql-test/t/rpl_stm_until.test:
Auto merged
sql/item_func.cc:
Auto merged
sql/lock.cc:
Auto merged
sql/sql_lex.h:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_union.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
sql/unireg.h:
Auto merged
storage/ndb/src/kernel/SimBlockList.cpp:
Auto merged
storage/ndb/src/kernel/blocks/ndbcntr/NdbcntrInit.cpp:
Auto merged
The bug caused wrong result sets for union constructs of the form
(SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2.
For such queries order lists were concatenated and limit clause was
completely neglected.
mysql-test/r/order_by.result:
Added a test case for bug #18767.
mysql-test/t/order_by.test:
Added a test case for bug #18767.
sql/sql_lex.h:
Fixed bug #18767.
Placed the code the created a fake SELECT_LEX into a separate function.
sql/sql_parse.cc:
Fixed bug #18767.
Placed the code the created a fake SELECT_LEX into a separate function.
sql/sql_select.cc:
Fixed bug #18767.
Changed the condition on which a SELECT is treated as part of a UNION.
The SELECT in
(SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2
now is handled in the same way as the first SELECT in a UNION
sequence.
sql/sql_union.cc:
Fixed bug #18767.
Changed the condition at which a SELECT is treated as part of a UNION.
The SELECT in
(SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2
now is handled in the same way as the first SELECT in a UNION
sequence.
sql/sql_yacc.yy:
Fixed bug #18767.
Changed the condition at which a SELECT is treated as part of a UNION.
The SELECT in
(SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2
now is handled in the same way as the first SELECT in a UNION
sequence. In the same way is handled the SELECT in
(SELECT ... LIMIT n) ORDER BY order list.
Yet if there is neither ORDER BY nor LIMIT in the single-select
union construct
(SELECT ...) ORDER BY order_list
then it is still handled as simple select with an order clause.
The bug caused wrong result sets for union constructs of the form
(SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2.
For such queries order lists were concatenated and limit clause was
completely neglected.
The SQL standard doesn't allow to use in HAVING clause fields that are not
present in GROUP BY clause and not under any aggregate function in the HAVING
clause. However, mysql allows using such fields. This extension assume that
the non-grouping fields will have the same group-wise values. Otherwise, the
result will be unpredictable. This extension allowed in strict
MODE_ONLY_FULL_GROUP_BY sql mode results in misunderstanding of HAVING
capabilities.
The new error message ER_NON_GROUPING_FIELD_USED message is added. It says
"non-grouping field '%-.64s' is used in %-.64s clause". This message is
supposed to be used for reporting errors when some field is not found in the
GROUP BY clause but have to be present there. Use cases for this message are
this bug and when a field is present in a SELECT item list not under any
aggregate function and there is GROUP BY clause present which doesn't mention
that field. It renders the ER_WRONG_FIELD_WITH_GROUP error message obsolete as
being more descriptive.
The resolve_ref_in_select_and_group() function now reports the
ER_NON_GROUPING_FIELD_FOUND error if the strict mode is set and the field for
HAVING clause is found in the SELECT item list only.
sql/share/errmsg.txt:
Added the new ER_NON_GROUPING_FIELD_USED error message for the bug#14169.
mysql-test/t/having.test:
Added test case for the bug#18739: non-standard HAVING extension was allowed in strict ANSI sql mode.
mysql-test/r/having.result:
Added test case for the bug#18739: non-standard HAVING extension was allowed in strict ANSI sql mode.
sql/sql_select.cc:
Added TODO comment to change the ER_WRONG_FIELD_WITH_GROUP to more detailed ER_NON_GROUPING_FIELD_USED message.
sql/item.cc:
Fixed bug#18739: non-standard HAVING extension was allowed in strict ANSI sql mode.
The resolve_ref_in_select_and_group() function now reports the
ER_NON_GROUPING_FIELD_FOUND error if the strict MODE_ONLY_FULL_GROUP_BY mode
is set and the field for HAVING clause is found in the SELECT item list only.
The SQL standard doesn't allow to use in HAVING clause fields that are not
present in GROUP BY clause and not under any aggregate function in the HAVING
clause. However, mysql allows using such fields. This extension assume that
the non-grouping fields will have the same group-wise values. Otherwise, the
result will be unpredictable. This extension allowed in strict
MODE_ONLY_FULL_GROUP_BY sql mode results in misunderstanding of HAVING
capabilities.
The new error message ER_NON_GROUPING_FIELD_USED message is added. It says
"non-grouping field '%-.64s' is used in %-.64s clause". This message is
supposed to be used for reporting errors when some field is not found in the
GROUP BY clause but have to be present there. Use cases for this message are
this bug and when a field is present in a SELECT item list not under any
aggregate function and there is GROUP BY clause present which doesn't mention
that field. It renders the ER_WRONG_FIELD_WITH_GROUP error message obsolete as
being more descriptive.
The resolve_ref_in_select_and_group() function now reports the
ER_NON_GROUPING_FIELD_FOUND error if the strict mode is set and the field for
HAVING clause is found in the SELECT item list only.
Fixing part2 of this problem: AND didn't work well
with utf8_czech_ci and utf8_lithianian_ci in some cases.
The problem was because when during condition optimization
field was replaced with a constant, the constant's collation
and collation derivation was used later for comparison instead
of the field collation and derivation, which led to non-equal
new condition in some cases.
This patch copies collation and derivation from the field being removed
to the new constant, which makes comparison work using the same collation
with the one which would be used if no condition optimization were done.
In other words:
where s1 < 'K' and s1 = 'Y';
was rewritten to:
where 'Y' < 'K' and s1 = 'Y';
Now it's rewritten to:
where 'Y' collate collation_of_s1 < 'K' and s1 = 'Y'
(using derivation of s1)
Note, the first problem of this bug (with latin1_german2_ci) was fixed
earlier in 5.0 tree, in a separate changeset.
mysql-test/r/ctype_utf8.result:
Adding test case
mysql-test/t/ctype_utf8.test:
Adding test case
sql/sql_select.cc:
Set proper collation of the new item
Fixing part2 of this problem: AND didn't work well
with utf8_czech_ci and utf8_lithianian_ci in some cases.
The problem was because when during condition optimization
field was replaced with a constant, the constant's collation
and collation derivation was used later for comparison instead
of the field collation and derivation, which led to non-equal
new condition in some cases.
This patch copies collation and derivation from the field being removed
to the new constant, which makes comparison work using the same collation
with the one which would be used if no condition optimization were done.
In other words:
where s1 < 'K' and s1 = 'Y';
was rewritten to:
where 'Y' < 'K' and s1 = 'Y';
Now it's rewritten to:
where 'Y' collate collation_of_s1 < 'K' and s1 = 'Y'
(using derivation of s1)
Note, the first problem of this bug (with latin1_german2_ci) was fixed
earlier in 5.0 tree, in a separate changeset.
used
In a simple queries a result of the GROUP_CONCAT() function was always of
varchar type.
But if length of GROUP_CONCAT() result is greater than 512 chars and temporary
table is used during select then the result is converted to blob, due to
policy to not to store fields longer than 512 chars in tmp table as varchar
fields.
In order to provide consistent behaviour, result of GROUP_CONCAT() now
will always be converted to blob if it is longer than 512 chars.
Item_func_group_concat::field_type() is modified accordingly.
mysql-test/t/func_gconcat.test:
Added test case for bug#14169: type of group_concat() result changed to blob if tmp_table was used
mysql-test/r/func_gconcat.result:
Added test case for bug#14169: type of group_concat() result changed to blob if tmp_table was used
sql/unireg.h:
Added the CONVERT_IF_BIGGER_TO_BLOB constant
sql/sql_select.cc:
Fixed bug#14169: type of group_concat() result changed to blob if tmp_table was used
The unnamed constant 255 in the create_tmp_field() and create_tmp_field_from_item() functions now defined as the CONVERT_IF_BIGGER_TO_BLOB constant.
The create_tmp_field() function now converts the Item_sum string result to a blob field based on its char length.
sql/item_sum.h:
Fixed bug#14169: type of group_concat() result changed to blob if tmp_table was used
To the Item_func_group_concat calls added the member function field_type() which returns the BLOB or VAR_STRING type based on the items length.
sql/item_func.cc:
Fixed bug#14169: type of group_concat() result changed to blob if tmp_table was used
In the Item_func::tmp_table_field() function the unnamed constant 255 is changed to the CONVERT_IF_BIGGER_TO_BLOB constant.
The Item_func::tmp_table_field() function now measures the result length in chars rather than bytes when converting string result to a blob.
used
In a simple queries a result of the GROUP_CONCAT() function was always of
varchar type.
But if length of GROUP_CONCAT() result is greater than 512 chars and temporary
table is used during select then the result is converted to blob, due to
policy to not to store fields longer than 512 chars in tmp table as varchar
fields.
In order to provide consistent behaviour, result of GROUP_CONCAT() now
will always be converted to blob if it is longer than 512 chars.
Item_func_group_concat::field_type() is modified accordingly.
into rurik.mysql.com:/home/igor/dev/mysql-5.1-0
mysql-test/r/ctype_utf8.result:
Auto merged
mysql-test/r/func_gconcat.result:
Auto merged
mysql-test/r/subselect.result:
Auto merged
sql/field.cc:
Auto merged
sql/ha_heap.cc:
Auto merged
sql/item.cc:
Auto merged
sql/item_cmpfunc.cc:
Auto merged
sql/item_sum.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_table.cc:
Auto merged
storage/myisam/mi_search.c:
Auto merged
storage/ndb/tools/Makefile.am:
Auto merged
strings/ctype-ucs2.c:
Auto merged
tests/mysql_client_test.c:
Auto merged
Multiple equalities were not adjusted after reading constant tables.
It resulted in neglecting good index based methods that could be
used to access of other tables.
mysql-test/r/having.result:
Adjusted a test case results after fix for bug #16504.
mysql-test/r/select.result:
Added a test case for bug #16504.
mysql-test/r/subselect.result:
Adjusted a test case results after fix for bug #16504.
mysql-test/r/varbinary.result:
Adjusted a test case results after fix for bug #16504.
mysql-test/t/select.test:
Added a test case for bug #16504.
sql/item.cc:
Fixed bug #16504.
An Item_equal object may contain only a constant member.
It may happen after reading constant tables.
sql/item_cmpfunc.cc:
Fixed bug #16504.
Added method Item_equal::check_const that check appearance of new
constant items in a multiple equality.
sql/item_cmpfunc.h:
Fixed bug #16504.
Added method Item_equal::check_const that check appearance of new
constant items in a multiple equality.
sql/sql_select.cc:
Fixed bug #16504.
Adjusted multiple equalities after reading constant tables.
Fixed a few typo in comments.
Multiple equalities were not adjusted after reading constant tables.
It resulted in neglecting good index based methods that could be
used to access of other tables.
into rurik.mysql.com:/home/igor/dev/mysql-5.1-0
mysql-test/r/loaddata.result:
Auto merged
mysql-test/r/ndb_read_multi_range.result:
Auto merged
mysql-test/t/innodb.test:
Auto merged
mysql-test/t/loaddata.test:
Auto merged
mysql-test/t/ndb_read_multi_range.test:
Auto merged
sql/field.cc:
Auto merged
sql/ha_ndbcluster.cc:
Auto merged
sql/sql_load.cc:
Auto merged
sql/sql_select.cc:
Auto merged
storage/ndb/tools/Makefile.am:
Auto merged
into mysql.com:/opt/local/work/mysql-5.1-merge
mysql-test/r/ps.result:
Auto merged
mysql-test/r/sp-error.result:
Auto merged
mysql-test/r/sp-prelocking.result:
Auto merged
mysql-test/r/sp.result:
Auto merged
mysql-test/r/trigger.result:
Auto merged
mysql-test/t/ps.test:
Auto merged
mysql-test/t/sp-error.test:
Auto merged
mysql-test/t/sp.test:
Auto merged
mysql-test/t/trigger.test:
Auto merged
sql/field.h:
Auto merged
sql/sp.cc:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_load.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_view.cc:
Auto merged
mysql-test/t/sp-prelocking.test:
Manual merge.
After merge fix for bug#15560
item_sum.h:
After merge fix for bug#15560
sql/sql_select.cc:
After merge fix for bug#15560
sql/item_sum.h:
After merge fix for bug#15560
sql/item_sum.cc:
After merge fix for bug#15560
into rurik.mysql.com:/home/igor/dev/mysql-5.1-0
mysql-test/r/loaddata.result:
Auto merged
mysql-test/r/ndb_read_multi_range.result:
Auto merged
mysql-test/t/innodb.test:
Auto merged
mysql-test/t/loaddata.test:
Auto merged
mysql-test/t/ndb_read_multi_range.test:
Auto merged
sql/field.cc:
Auto merged
sql/ha_ndbcluster.cc:
Auto merged
sql/sql_load.cc:
Auto merged
sql/sql_prepare.cc:
Auto merged
sql/sql_select.cc:
Auto merged
storage/ndb/tools/Makefile.am:
Auto merged
out of a nested join to the on conditions for the nest.
The bug happened due to:
1. The function simplify_joins could change on expressions for nested joins.
Yet modified on expressions were not saved in prep_on_expr.
2. On expressions were not restored for nested joins in
reinit_stmt_before_use.
mysql-test/r/join_nested.result:
Added a test case for bug #18279.
mysql-test/t/join_nested.test:
Added a test case for bug #18279.
sql/sql_prepare.cc:
Fixed bug #18279.
On expressions were not restored for nested joins in
reinit_stmt_before_use.
sql/sql_select.cc:
Fixed bug #18279.
The function simplify_joins could change on expressions for nested joins.
Yet modified on expressions were not saved in prep_on_expr.
