The columns in HAVING can reference the GROUP BY and
SELECT columns. There can be "table" prefixes when
referencing these columns. And these "table" prefixes
in HAVING use the table alias if available.
This means that table aliases are subject to the same
storage rules as table names and are dependent on
lower_case_table_names in the same way as the table
names are.
Fixed by :
1. Treating table aliases as table names
and make them lowercase when printing out the SQL
statement for view persistence.
2. Using case insensitive comparison for table
aliases when requested by lower_case_table_names
mysql-test/r/lowercase_view.result:
Bug #31562: test case
mysql-test/t/lowercase_view.test:
Bug #31562: test case
sql/item.cc:
Bug #31562: lower_case_table_name contious comparison
when searching in GROUP BY
sql/sql_base.cc:
Bug #31562: lower_case_table_name contious comparison
when searching in SELECT
sql/sql_select.cc:
Bug #31562: treat table aliases as table names
and make them lowercase when printing
The columns in HAVING can reference the GROUP BY and
SELECT columns. There can be "table" prefixes when
referencing these columns. And these "table" prefixes
in HAVING use the table alias if available.
This means that table aliases are subject to the same
storage rules as table names and are dependent on
lower_case_table_names in the same way as the table
names are.
Fixed by :
1. Treating table aliases as table names
and make them lowercase when printing out the SQL
statement for view persistence.
2. Using case insensitive comparison for table
aliases when requested by lower_case_table_names
into polly.(none):/home/kaa/src/opt/bug30666/my51-bug29131
mysql-test/r/select.result:
Auto merged
mysql-test/t/select.test:
Auto merged
sql/sql_select.cc:
Auto merged
UNIQUE (eq-ref) lookups result in table being considered as a "constant" table.
Queries that consist of only constant tables are processed in do_select() in a
special way that doesn't invoke evaluate_join_record(), and therefore doesn't
increase the counters join->examined_rows and join->thd->row_count.
The patch increases these counters in this special case.
NOTICE:
This behavior seems to contradict what the documentation says in Sect. 5.11.4:
"Queries handled by the query cache are not added to the slow query log, nor
are queries that would not benefit from the presence of an index because the
table has zero rows or one row."
No test case in 5.0 as issue shows only in slow query log, and other counters
can give subtly different values (with regard to counting in create_sort_index(),
synthetic rows in ROLLUP, etc.).
sql/sql_class.h:
add documentation for some variables
sql/sql_select.cc:
Don't forget const tables when counting read records!
UNIQUE (eq-ref) lookups result in table being considered as a "constant" table.
Queries that consist of only constant tables are processed in do_select() in a
special way that doesn't invoke evaluate_join_record(), and therefore doesn't
increase the counters join->examined_rows and join->thd->row_count.
The patch increases these counters in this special case.
NOTICE:
This behavior seems to contradict what the documentation says in Sect. 5.11.4:
"Queries handled by the query cache are not added to the slow query log, nor
are queries that would not benefit from the presence of an index because the
table has zero rows or one row."
No test case in 5.0 as issue shows only in slow query log, and other counters
can give subtly different values (with regard to counting in create_sort_index(),
synthetic rows in ROLLUP, etc.).
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.1-forcollapseandmerge
sql/ha_ndbcluster.cc:
Auto merged
sql/item_func.cc:
Auto merged
sql/log_event.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/mysqld.cc:
Auto merged
sql/set_var.cc:
Auto merged
sql/slave.cc:
Auto merged
sql/sp_head.cc:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_class.cc:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_delete.cc:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_lex.h:
Auto merged
sql/sql_prepare.cc:
Auto merged
sql/sql_table.cc:
Auto merged
sql/sql_update.cc:
Auto merged
sql/sql_view.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
sql/table.h:
Auto merged
sql/sql_parse.cc:
Manual merge.
sql/sql_select.cc:
Manual merge.
The bug is a regression introduced by the fix for bug30596. The problem
was that in cases when groups in GROUP BY correspond to only one row,
and there is ORDER BY, the GROUP BY was removed and the ORDER BY
rewritten to ORDER BY <group_by_columns> without checking if the
columns in GROUP BY and ORDER BY are compatible. This led to
incorrect ordering of the result set as it was sorted using the
GROUP BY columns. Additionaly, the code discarded ASC/DESC modifiers
from ORDER BY even if its columns were compatible with the GROUP BY
ones.
This patch fixes the regression by checking if ORDER BY columns form a
prefix of the GROUP BY ones, and rewriting ORDER BY only in that case,
preserving the ASC/DESC modifiers. That check is sufficient, since the
GROUP BY columns contain a unique index.
mysql-test/r/group_by.result:
Added a test case for bug #32202.
mysql-test/t/group_by.test:
Added a test case for bug #32202.
sql/sql_select.cc:
In cases when groups in GROUP BY correspond to only one row and there
is ORDER BY, rewrite the query to ORDER BY <group_by_columns> only if
the columns in ORDER BY and GROUP BY are compatible, i.e. either one
forms a prefix for another.
The bug is a regression introduced by the fix for bug30596. The problem
was that in cases when groups in GROUP BY correspond to only one row,
and there is ORDER BY, the GROUP BY was removed and the ORDER BY
rewritten to ORDER BY <group_by_columns> without checking if the
columns in GROUP BY and ORDER BY are compatible. This led to
incorrect ordering of the result set as it was sorted using the
GROUP BY columns. Additionaly, the code discarded ASC/DESC modifiers
from ORDER BY even if its columns were compatible with the GROUP BY
ones.
This patch fixes the regression by checking if ORDER BY columns form a
prefix of the GROUP BY ones, and rewriting ORDER BY only in that case,
preserving the ASC/DESC modifiers. That check is sufficient, since the
GROUP BY columns contain a unique index.
into hynda.mysql.fi:/home/my/mysql-5.1-marvel
BitKeeper/etc/ignore:
auto-union
client/mysql_upgrade.c:
Auto merged
client/mysqlcheck.c:
Auto merged
client/mysqldump.c:
Auto merged
client/mysqlimport.c:
Auto merged
client/mysqlshow.c:
Auto merged
client/mysqlslap.c:
Auto merged
client/mysqltest.c:
Auto merged
include/my_global.h:
Auto merged
include/my_sys.h:
Auto merged
mysys/mf_keycache.c:
Auto merged
mysys/my_init.c:
Auto merged
mysys/safemalloc.c:
Auto merged
sql/ha_partition.cc:
Auto merged
sql/handler.cc:
Auto merged
sql/item_func.cc:
Auto merged
sql/log.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/mysqld.cc:
Auto merged
sql/opt_range.cc:
Auto merged
sql/set_var.cc:
Auto merged
sql/sql_class.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_show.cc:
Auto merged
sql/sql_table.cc:
Auto merged
sql/table.cc:
Auto merged
sql/table.h:
Auto merged
sql/unireg.cc:
Auto merged
storage/myisam/ha_myisam.cc:
Auto merged
storage/myisam/mi_write.c:
Auto merged
sql/sql_yacc.yy:
Merged with 5.1 main tree.
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.
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.
tables or more
The problem was that the optimizer used the join buffer in cases when
the result set is ordered by filesort. This resulted in the ORDER BY
clause being ignored, and the records being returned in the order
determined by the order of matching records in the last table in join.
Fixed by relaxing the condition in make_join_readinfo() to take
filesort-ordered result sets into account, not only index-ordered ones.
mysql-test/r/select.result:
Added a test case for bug #30666.
mysql-test/t/select.test:
Added a test case for bug #30666.
sql/sql_select.cc:
Relaxed the condition to determine when the join buffer usage must be
disabled. The condition is now true for cases when the result set is
ordered by filesort, that is when 'join->order &&
!join->skip_sort_order' is true.
tables or more
The problem was that the optimizer used the join buffer in cases when
the result set is ordered by filesort. This resulted in the ORDER BY
clause being ignored, and the records being returned in the order
determined by the order of matching records in the last table in join.
Fixed by relaxing the condition in make_join_readinfo() to take
filesort-ordered result sets into account, not only index-ordered ones.
The fix for bug 31148 is not correct. It does not
have a relation to the problem described in this bug.
And removing the fix will not make the bug to re-appear.
Fixed the bug #31974 by removing the fix for bug 31148
and adding a test case.
mysql-test/r/key.result:
Bug #31974: test case
mysql-test/t/key.test:
Bug #31974: test case
sql/sql_select.cc:
Bug #31974: revert the fix for bug 31148
The fix for bug 31148 is not correct. It does not
have a relation to the problem described in this bug.
And removing the fix will not make the bug to re-appear.
Fixed the bug #31974 by removing the fix for bug 31148
and adding a test case.
added 'in_rows' column value for 'describe extended' for the case
when 'describe' handles I_S table
mysql-test/r/information_schema.result:
test result
mysql-test/t/information_schema.test:
test case
sql/sql_select.cc:
added 'in_rows' column value for 'describe extended' for the case
when 'describe' handles I_S table
into magare.gmz:/home/kgeorge/mysql/work/B31794-5.1-opt
mysql-test/r/func_group.result:
Auto merged
mysql-test/t/func_group.test:
Auto merged
sql/sql_select.cc:
Auto merged
The HAVING clause is subject to the same rules as the SELECT list
about using aggregated and non-aggregated columns.
But this was not enforced when processing implicit grouping from
using aggregate functions.
Fixed by performing the same checks for HAVING as for SELECT.
mysql-test/r/func_group.result:
Bug #31794: test case
mysql-test/t/func_group.test:
Bug #31794: test case
sql/sql_select.cc:
Bug #31794: Check HAVING in addition to SELECT list
The HAVING clause is subject to the same rules as the SELECT list
about using aggregated and non-aggregated columns.
But this was not enforced when processing implicit grouping from
using aggregate functions.
Fixed by performing the same checks for HAVING as for SELECT.
in evaluate_join_record().
A minor cleanup required for the fix for Bug#12713.
sql/sql_select.cc:
Use thd->is_error() instead of direct access to thd->net.report_error
in evaluate_join_record()
