sql/sql_insert.cc:
CREATE ... IF NOT EXISTS may do nothing, but
it is still not a failure. don't forget to my_ok it.
******
CREATE ... IF NOT EXISTS may do nothing, but
it is still not a failure. don't forget to my_ok it.
sql/sql_table.cc:
small cleanup
******
small cleanup
in opt_range.h
In this bug, there are two alternative access plans:
* Index merge range access
* Const ref access
best_access_path() decided that the ref access was preferrable,
but make_join_select() still decided to point
SQL_SELECT::quick to the index merge because the table had
type==JT_CONST which was not handled.
At the same time the table's ref.key still referred to the
index the ref access would use indicating that ref access
should be used. In this state, different parts of the
optimizer code have different perceptions of which access path
is in use (ref or range).
test_if_skip_sort_order() was called to check if the ref access
needed ordering, but test_if_skip_sort_order() got confused and
requested the index merge to return records in sorted order.
Index merge cannot do this, and fired an ASSERT.
The fix is to take join_tab->type==JT_CONST into concideration
when make_join_select() decides whether or not to use the
range access method.
mysql-test/r/join_outer_innodb.result:
Add test for BUG#58456
mysql-test/t/join_outer_innodb.test:
Add test for BUG#58456
WL#2474 "Multi Range Read: Change the default MRR implementation to implement new MRR interface"
WL#2475 "Batched range read functions for MyISAM/InnoDb"
"Index condition pushdown for MyISAM/InnoDB"
Igor's fix from sp1r-igor@olga.mysql.com-20080330055902-07614:
There could be observed the following problems:
1. EXPLAIN did not mention pushdown conditions from on expressions in the
'extra' column. As a result if a query had no where conditions pushed
down to a table, but had on conditions pushed to this table the 'extra'
column in the EXPLAIN for the table missed 'using where'.
2. Conditions for ref access were not eliminated from on expressions
though such conditions were eliminated from the where condition.
- Disable the "prefer full scan on clustered primary key over full scan
of any secondary key" rule introduced by BUG#35850.
- Update test results accordingly
(bk trigger: file this for BUG#35850)
mysql-test/r/innodb.result:
BUG#35850 "Performance regression in 5.1.23/5.1.24"
- Update test results
mysql-test/r/innodb_mysql.result:
BUG#35850 "Performance regression in 5.1.23/5.1.24"
- Testcase
- Update test results
mysql-test/r/join_outer_innodb.result:
BUG#35850 "Performance regression in 5.1.23/5.1.24"
- Update test results
mysql-test/t/innodb_mysql.test:
BUG#35850 "Performance regression in 5.1.23/5.1.24"
- Testcase
sql/sql_select.cc:
BUG#35850 "Performance regression in 5.1.23/5.1.24"
- Disable the "prefer full scan on clustered primary key over full scan
of any secondary key" rule introduced by BUG#35850.
and auto_increment keys
Problems:
1. ALTER TABLE ... ORDER BY... doesn't make sence if there's a
user-defined clustered index in the table.
2. using a secondary index is slower than using a clustered one
for a table scan.
Fixes:
1. raise a warning.
2. use the clustered index.
mysql-test/include/mix1.inc:
Fix for bug #26447: "ALTER TABLE .. ORDER" does not work with InnoDB
and auto_increment keys
- test case.
mysql-test/r/innodb.result:
Fix for bug #26447: "ALTER TABLE .. ORDER" does not work with InnoDB
and auto_increment keys
- results adjusted.
mysql-test/r/innodb_mysql.result:
Fix for bug #26447: "ALTER TABLE .. ORDER" does not work with InnoDB
and auto_increment keys
- results adjusted.
mysql-test/r/join_outer_innodb.result:
Fix for bug #26447: "ALTER TABLE .. ORDER" does not work with InnoDB
and auto_increment keys
- results adjusted.
sql/sql_select.cc:
Fix for bug #26447: "ALTER TABLE .. ORDER" does not work with InnoDB
and auto_increment keys
- use the clustered index for a table scan (if any) as it's faster than
using a secondary index.
sql/sql_table.cc:
Fix for bug #26447: "ALTER TABLE .. ORDER" does not work with InnoDB
and auto_increment keys
- ALTER TABLE ... ORDER BY doesn't make sence if there's a
user-defined clustered index in the table. Ignore it in such cases
and raise a warning.
Fix merge problem
mysql-test/r/join_outer_innodb.result:
Update test result
mysql-test/t/group_min_max.test:
Add missing drop table (lost during merge)
mysql-test/r/join_outer_innodb.result:
New BitKeeper file ``mysql-test/r/join_outer_innodb.result''
mysql-test/t/join_outer_innodb.test:
New BitKeeper file ``mysql-test/t/join_outer_innodb.test''
