Analysis:
st_select_lex_unit::prepare() computes can_skip_order_by as TRUE.
As a result join->prepare() gets called with order == NULL, and
doesn't do name resolution for the inner ORDER clause. Due to this
the prepare phase doesn't detect that the query references non-exiting
function and field.
Later join->optimize() calls update_used_tables() for a non-resolved
Item_field, which understandably has no Field object. This call results
in a crash.
Solution:
Resolve unnecessary ORDER BY clauses to detect if they reference non-exising
objects. Then remove such clauses from the JOIN object.
Analysis:
Range analysis discoveres that the query can be executed via loose index scan for GROUP BY.
Later, GROUP BY analysis fails to confirm that the GROUP operation can be computed via an
index because there is no logic to handle duplicate field references in the GROUP clause.
As a result the optimizer produces an inconsistent plan. It constructs a temporary table,
but on the other hand the group fields are not set to point there.
Solution:
Make loose scan analysis work in sync with order by analysis. In the case of duplicate
columns loose scan will not be applicable. This limitation will be lifted in 10.0 by
removing duplicate columns.
If the setting of system variables does not allow to use join buffer
for a join query with GROUP BY <f1,...> / ORDER BY <f1,...> then
filesort is not needed if the first joined table is scanned in
the order compatible with order specified by the list <f1,...>.
fix: don't call field->val_decimal() if the field->is_null()
because the buffer at field->ptr might not hold a valid decimal value
sql/item_sum.cc:
do not call field->val_decimal() if the field->is_null()
storage/maria/ma_blockrec.c:
cleanup
storage/maria/ma_rrnd.c:
cleanup
strings/decimal.c:
typo
Optimization of aggregate functions detected constant under max() and evalueted it, but condition in the WHWRE clause (which is always FALSE) was not taken into account
The patch backports two patches from mysql 5.6:
- BUG#12640437: USING SQL_BUFFER_RESULT RESULTS IN A DIFFERENT QUERY OUTPUT
- Bug#12578908: SELECT SQL_BUFFER_RESULT OUTPUTS TOO MANY ROWS WHEN GROUP IS OPTIMIZED AWAY
Original comment:
-----------------
3714 Jorgen Loland 2012-03-01
BUG#12640437 - USING SQL_BUFFER_RESULT RESULTS IN A DIFFERENT
QUERY OUTPUT
For all but simple grouped queries, temporary tables are used to
resolve grouping. In these cases, the list of grouping fields is
stored in the temporary table and grouping is resolved
there (e.g. by adding a unique constraint on the involved
fields). Because of this, grouping is already done when the rows
are read from the temporary table.
In the case where a group clause may be optimized away, grouping
does not have to be resolved using a temporary table. However, if
a temporary table is explicitly requested (e.g. because the
SQL_BUFFER_RESULT hint is used, or the statement is
INSERT...SELECT), a temporary table is used anyway. In this case,
the temporary table is created with an empty group list (because
the group clause was optimized away) and it will therefore not
create groups. Since the temporary table does not take care of
grouping, JOIN::group shall not be set to false in
make_simple_join(). This was fixed in bug 12578908.
However, there is an exception where make_simple_join() should
set JOIN::group to false even if the query uses a temporary table
that was explicitly requested but is not strictly needed. That
exception is if the loose index scan access method (explain
says "Using index for group-by") is used to read into the
temporary table. With loose index scan, grouping is resolved
by the access method. This is exactly what happens in this bug.
The problem was in the code (update_const_equal_items()) which marked
index parts constant independently of the place where the equality was used.
In the test suite it marked t2_1.c part constant despite the fact that
it connected by OR with other expression.
Solution is to mark constant only top equalities connected with AND.
GROUPING BY FUNCTIONS.... (PART
The bug was introduced in a patch for bug 49897.
Problem: The assertion inserted by the original patch to guard against
zero-lenght sort keys during merge phase triggers also when the whole
set fits in memory.
Fix: Move assert so that it does not trigger if the whole set is in
memory.
mysql-test/r/group_by.result:
Add test for bug#11765254
mysql-test/t/group_by.test:
Add test for bug#11765254
sql/filesort.cc:
Move assertion
The loop that was looping over subqueries' references to outer field used a
local boolean variable to tell whether the field was grouped or not. But the
implementor failed to reset the variable after each iteration. Thus a field
that was not directly aggregated appeared to be.
Fixed by resetting the variable upon each new iteration.
Open issues:
- A better fix for #57688; Igor is working on this
- Test failure in index_merge_innodb.test ; Igor promised to look at this
- Some Innodb tests fails (need to merge with latest xtradb) ; Kristian promised to look at this.
- Failing tests: innodb_plugin.innodb_bug56143 innodb_plugin.innodb_bug56632 innodb_plugin.innodb_bug56680 innodb_plugin.innodb_bug57255
- Werror is disabled; Should be enabled after merge with xtradb.
Lines below which were added in the patch for Bug#56814 cause this crash:
+ if (table->table)
+ table->table->maybe_null= FALSE;
Consider following test case:
--
CREATE TABLE t1(f1 INT NOT NULL);
INSERT INTO t1 VALUES (16777214),(0);
SELECT COUNT(*) FROM t1 LEFT JOIN t1 t2
ON 1 WHERE t2.f1 > 1 GROUP BY t2.f1;
DROP TABLE t1;
--
We set TABLE::maybe_null to FALSE for t2 table
and in create_tmp_field() we create appropriate tmp table field
using create_tmp_field_from_item() function instead of
create_tmp_field_from_field. As a result we have
LONGLONG field. As we have GROUP BY clause we calculate
group buffer length, see calc_group_buffer().
Item from group list which is used for calculation
refer to the field from real tables and have LONG type.
So group buffer length become insufficient for storing of
LONGLONG value. It leads to overwriting of wrong memory
area in do_field_int() function which is called from
end_update().
After some investigation I found out that
create_tmp_field_from_item() is used only for OLAP
grouping and can not be used for common grouping
as it could be an incompatibility between tmp
table fields and group buffer length.
We can not remove create_tmp_field_from_item() call from
create_tmp_field as OLAP needs it and we can not use this
function for common grouping. So we should remove setting
TABLE::maybe_null to FALSE from simplify_joins().
In this case we'll get wrong behaviour of
list_contains_unique_index() back. To fix it we
could use Field::real_maybe_null() check instead of
Field::maybe_null() and add addition check of
TABLE_LIST::outer_join.
mysql-test/r/group_by.result:
test case
mysql-test/r/join_outer.result:
test case
mysql-test/t/group_by.test:
test case
mysql-test/t/join_outer.test:
test case
sql/sql_select.cc:
--remove wrong code
--use Field::real_maybe_null() check instead of
Field::maybe_null() and add addition check of
TABLE_LIST::outer_join
- Changed to still use bcmp() in certain cases becasue
- Faster for short unaligneed strings than memcmp()
- Bettern when using valgrind
- Changed to use my_sprintf() instead of sprintf() to get higher portability for old systems
- Changed code to use MariaDB version of select->skip_record()
- Removed -%::SCCS/s.% from Makefile.am:s to remove automake warnings
mysql-test/r/group_by.result:
Added test that showed problems that no_rows_in_results() didn't work for expressions
mysql-test/r/subselect4.result:
Test case for LP#612894
mysql-test/t/group_by.test:
Added test that showed problems that no_rows_in_results() didn't work for expressions
mysql-test/t/subselect4.test:
Test case for LP#612894
sql/item.h:
Added restore_to_before_no_rows_in_result()
Added function processor for no_rows_in_results() and restore_to_before_no_rows_in_results() to ensure it works with functions
Fix that above functions are handled by Item_ref()
sql/item_func.h:
Ensure that no_rows_in_results() and restore_to_before_no_rows_in_result() are called for all function arguments
sql/item_sum.cc:
Added restore_to_before_no_rows_in_result() to restore settings after Item_sum_hybrid::no_rows_in_result() was called.
This is needed to handle the case where we have made 'make_const()' on the item in opt_sum(), but the item will be reused again in a sub query.
Ignore multiple calls to no_rows_in_result() as Item_ref is calling it twice.
sql/item_sum.h:
Added restore_to_before_no_rows_in_result();
sql/sql_select.cc:
Added reset of no_rows_in_result() for JOIN::reinit()
sql/sql_select.h:
Added marker if no_rows_in_result() is called.
In order to be able to check if the set of the grouping fields in a
GROUP BY has changed (and thus to start a new group) the optimizer
caches the current values of these fields in a set of Cached_item
derived objects.
The Cached_item_str, used for caching varchar and TEXT columns,
is limited in length by the max_sort_length variable.
A String buffer to store the value with an alloced length of either
the max length of the string or the value of max_sort_length
(whichever is smaller) in Cached_item_str's constructor.
Then, at compare time the value of the string to compare to was
truncated to the alloced length of the string buffer inside
Cached_item_str.
This is all fine and valid, but only if you're not assigning
values near or equal to the alloced length of this buffer.
Because when assigning values like this the alloced length is
rounded up and as a result the next set of data will not match the
group buffer, thus leading to wrong results because of the changed
alloced_length.
Fixed by preserving the original maximum length in the
Cached_item_str's constructor and using this instead of the
alloced_length to limit the string to compare to.
Test case added.
NULL from outer join query
Problem: optimising MIN/MAX() queries without GROUP BY clause
by replacing the aggregate expression with a constant, we may set it
to NULL disregarding the fact that there may be outer joins involved.
Fix: don't replace MIN/MAX() with NULL if there're outer joins.
Note: the fix itself is just
- if (!count)
+ if (!count && !outer_tables)
set to NULL
The rest of the patch eliminates repeated code to improve speed
and for easy maintenance of the code.
mysql-test/r/group_by.result:
Fix for bug#52051: Aggregate functions incorrectly returns
NULL from outer join query
- test result.
mysql-test/t/group_by.test:
Fix for bug#52051: Aggregate functions incorrectly returns
NULL from outer join query
- test case.
sql/opt_sum.cc:
Fix for bug#52051: Aggregate functions incorrectly returns
NULL from outer join query
- optimising MIN/MAX() queries without GROUP BY clause by
replacing them with a constant, take into account that
there're may be outer joins involved.
- repeated code for MIN/MAX optimization in the opt_sum_query()
eliminated by introducing new functions that read MIN/MAX values
using index and combining MIN/MAX cases to one.
Grouping by a subquery in a query with a distinct aggregate
function lead to a wrong result (wrong and unordered
grouping values).
There are two related problems:
1) The query like this:
SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c
FROM t1 GROUP BY aa
returned wrong result, because the outer reference "t1.a"
in the subquery was substituted with the Item_ref item.
The Item_ref item obtains data from the result_field object
that refreshes once after the end of each group. This data
is not applicable to filesort since filesort() doesn't care
about groups (and doesn't update result_field objects with
copy_fields() and so on). Also that data is not applicable
to group separation algorithm: end_send_group() checks every
record with test_if_group_changed() that evaluates Item_ref
items, but it refreshes those Item_ref-s only after the end
of group, that is a vicious circle and the grouped column
values in the output are shifted.
Fix: if
a) we grouping by a subquery and
b) that subquery has outer references to FROM list
of the grouping query,
then we substitute these outer references with
Item_direct_ref like references under aggregate
functions: Item_direct_ref obtains data directly
from the current record.
2) The query with a non-trivial grouping expression like:
SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c
FROM t1 GROUP BY aa+0
also returned wrong result, since JOIN::exec() substitutes
references to top-level aliases in SELECT list with Item_copy
caching items. Item_copy items have same refreshing policy
as Item_ref items, so the whole groping expression with
Item_copy inside returns wrong result in filesort() and
end_send_group().
Fix: include aliased items into GROUP BY item tree instead
of Item_ref references to them.
mysql-test/r/group_by.result:
Test case for bug #45640
mysql-test/t/group_by.test:
Test case for bug #45640
sql/item.cc:
Bug #45640: optimizer bug produces wrong results
Item_field::fix_fields() has been modified to resolve
aliases in GROUP BY item trees into aliased items instead
of Item_ref items.
sql/item.h:
Bug #45640: optimizer bug produces wrong results
- Item::find_item_processor() has been introduced.
- Item_ref::walk() has been modified to apply processors
to itself too (not only to referenced item).
sql/mysql_priv.h:
Bug #45640: optimizer bug produces wrong results
fix_inner_refs() has been modified to accept group_list
parameter.
sql/sql_lex.cc:
Bug #45640: optimizer bug produces wrong results
Initialization of st_select_lex::group_fix_field has
been added.
sql/sql_lex.h:
Bug #45640: optimizer bug produces wrong results
The st_select_lex::group_fix_field field has been introduced
to control alias resolution in Itef_fied::fix_fields.
sql/sql_select.cc:
Bug #45640: optimizer bug produces wrong results
- The fix_inner_refs function has been modified to treat
subquery outer references like outer fields under aggregate
functions, if they are included in GROUP BY item tree.
- The find_order_in_list function has been modified to
fix Item_field alias fields included in the GROUP BY item
trees in a special manner.
mysql-test/r/partition_not_windows.result:
Update warning number due to new errors appearing earlier
in the list.
mysql-test/r/partition_symlink.result:
Update warning number due to new errors appearing earlier
in the list.
mysql-test/r/symlink.result:
Update warning number due to new errors appearing earlier
in the list.
- Make send_row_on_empty_set() return FALSE when simplify_cond() has found out
that HAVING is always FALSE
re-committing to put the fix into 5.0 and 5.1
mysql-test/r/group_by.result:
BUG#38072: Wrong result: HAVING not observed in a query with aggregate
- Testcase
mysql-test/t/group_by.test:
BUG#38072: Wrong result: HAVING not observed in a query with aggregate
- Testcase
sql/sql_select.h:
BUG#38072: Wrong result: HAVING not observed in a query with aggregate
- Make send_row_on_empty_set() return FALSE when simplify_cond() has found out
that HAVING is always FALSE
into pilot.mysql.com:/data/msvensson/mysql/mysql-5.1-mtr
BitKeeper/etc/ignore:
auto-union
BitKeeper/deleted/.del-rpl_row_charset.test:
Auto merged
CMakeLists.txt:
Auto merged
configure.in:
Auto merged
client/mysqltest.c:
Auto merged
mysql-test/extra/binlog_tests/blackhole.test:
Auto merged
mysql-test/include/commit.inc:
Auto merged
mysql-test/include/mix1.inc:
Auto merged
mysql-test/lib/mtr_report.pm:
Auto merged
mysql-test/r/commit_1innodb.result:
Auto merged
mysql-test/r/create.result:
Auto merged
mysql-test/r/ctype_big5.result:
Auto merged
mysql-test/r/drop.result:
Auto merged
mysql-test/r/group_by.result:
Auto merged
mysql-test/r/information_schema.result:
Auto merged
mysql-test/r/loaddata.result:
Auto merged
mysql-test/r/mysqlbinlog.result:
Auto merged
mysql-test/r/partition_error.result:
Auto merged
mysql-test/r/query_cache.result:
Auto merged
mysql-test/r/sp.result:
Auto merged
mysql-test/r/view.result:
Auto merged
mysql-test/r/warnings.result:
Auto merged
mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result:
Auto merged
mysql-test/suite/binlog/r/binlog_stm_blackhole.result:
Auto merged
mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result:
Auto merged
mysql-test/suite/binlog/r/binlog_unsafe.result:
Auto merged
mysql-test/suite/binlog/t/binlog_unsafe.test:
Auto merged
mysql-test/suite/federated/federated.result:
Auto merged
mysql-test/suite/federated/federated.test:
Auto merged
mysql-test/suite/parts/r/partition_alter1_myisam.result:
Auto merged
mysql-test/suite/parts/r/partition_alter2_myisam.result:
Auto merged
mysql-test/suite/rpl/r/rpl_row_basic_11bugs.result:
Auto merged
mysql-test/suite/rpl/r/rpl_row_log.result:
Auto merged
mysql-test/suite/rpl/r/rpl_row_log_innodb.result:
Auto merged
mysql-test/suite/rpl/t/disabled.def:
Auto merged
mysql-test/suite/rpl/t/rpl_flushlog_loop.test:
Auto merged
mysql-test/suite/rpl_ndb/r/rpl_ndb_log.result:
Auto merged
mysql-test/suite/rpl_ndb/t/rpl_ndb_transaction.test:
Auto merged
mysql-test/t/create.test:
Auto merged
mysql-test/t/csv.test:
Auto merged
mysql-test/t/disabled.def:
Auto merged
mysql-test/t/distinct.test:
Auto merged
mysql-test/t/drop.test:
Auto merged
mysql-test/t/group_by.test:
Auto merged
mysql-test/t/innodb.test:
Auto merged
mysql-test/t/loaddata.test:
Auto merged
mysql-test/t/partition_error.test:
Auto merged
mysql-test/t/query_cache.test:
Auto merged
mysql-test/t/sp.test:
Auto merged
mysql-test/t/view.test:
Auto merged
mysql-test/t/warnings.test:
Auto merged
sql/ha_ndbcluster.cc:
Auto merged
BitKeeper/deleted/.del-combinations:
Delete: mysql-test/suite/binlog/combinations
mysql-test/r/partition_not_windows.result:
Use remote
mysql-test/r/partition_symlink.result:
Use remote
mysql-test/r/symlink.result:
SCCS merged
mysql-test/suite/parts/inc/partition_basic.inc:
SCCS merged
mysql-test/suite/parts/inc/partition_check_drop.inc:
Use remote
mysql-test/suite/parts/inc/partition_layout_check1.inc:
Use remote
mysql-test/suite/parts/inc/partition_layout_check2.inc:
Use remote
mysql-test/suite/parts/r/partition_basic_innodb.result:
Use remote
mysql-test/suite/parts/r/partition_basic_myisam.result:
Use remote
mysql-test/suite/parts/r/partition_engine_myisam.result:
Use remote
mysql-test/suite/parts/t/partition_sessions.test:
SCCS merged
mysql-test/t/partition.test:
SCCS merged
mysql-test/t/partition_not_windows.test:
Use remote
mysql-test/t/partition_symlink.test:
Use remote
mysql-test/t/symlink.test:
Use remote
mysql-test/suite/binlog/r/binlog_multi_engine.result:
Manual merge, name of binlog file changed
mysql-test/suite/rpl/t/rpl_row_mysqlbinlog.test:
Manual merge
mysys/my_init.c:
Manual merge
into moonbone.local:/work/27219-bug-5.1
sql/item_subselect.cc:
Auto merged
sql/item_sum.cc:
Auto merged
sql/item_sum.h:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/sql_lex.cc:
Auto merged
sql/sql_select.cc:
Auto merged
mysql-test/r/group_by.result:
SCCS merged
mysql-test/t/group_by.test:
SCCS merged
sql/item.cc:
SCCS merged
sql/sql_lex.h:
SCCS merged
Mixing aggregate functions and non-grouping columns is not allowed in the
ONLY_FULL_GROUP_BY mode. However in some cases the error wasn't thrown because
of insufficient check.
In order to check more thoroughly the new algorithm employs a list of outer
fields used in a sum function and a SELECT_LEX::full_group_by_flag.
Each non-outer field checked to find out whether it's aggregated or not and
the current select is marked accordingly.
All outer fields that are used under an aggregate function are added to the
Item_sum::outer_fields list and later checked by the Item_sum::check_sum_func
function.
mysql-test/t/group_by.test:
Added a test case for the bug#27219: Aggregate functions in ORDER BY.
mysql-test/r/group_by.result:
Added a test case for the bug#27219: Aggregate functions in ORDER BY.
sql/sql_select.cc:
Bug#27219: Aggregate functions in ORDER BY.
Implementation of new check for mixing non aggregated fields and aggregation
function in the ONLY_FULL_GROUP_BY mode.
sql/sql_lex.cc:
Bug#27219: Aggregate functions in ORDER BY.
Initialization of the full_group_by_flag bitmap.
SELECT_LEX::test_limit function doesn't reset ORDER BY
clause anymore.
sql/sql_lex.h:
Bug#27219: Aggregate functions in ORDER BY.
The full_group_by_flag is added to the SELECT_LEX class.
sql/item_sum.h:
Bug#27219: Aggregate functions in ORDER BY.
The outer_fields list is added to the Item_sum class.
sql/mysql_priv.h:
Bug#27219: Aggregate functions in ORDER BY.
Defined a set of constants used in the new check for mixing non aggregated
fields and sum functions in the ONLY_FULL_GROUP_BY_MODE.
sql/item_subselect.cc:
Bug#27219: Aggregate functions in ORDER BY.
The Item_in_subselect::select_in_like_transformer function now drops
ORDER BY clause in all selects in a subquery.
sql/item_sum.cc:
Bug#27219: Aggregate functions in ORDER BY.
Now the Item_sum::check_sum_func function now checks whether fields in the
outer_fields list are aggregated or not and marks selects accordingly.
sql/item.cc:
Bug#27219: Aggregate functions in ORDER BY.
Now the Item_field::fix_fields function checks whether the field is aggregated
or not and marks its select_lex accordingly.
into kaamos.(none):/data/src/opt/mysql-5.1-opt
mysql-test/r/group_by.result:
Auto merged
mysql-test/r/type_decimal.result:
Auto merged
mysql-test/r/view.result:
Auto merged
mysql-test/t/type_decimal.test:
Auto merged
sql/item.cc:
Auto merged
sql/item_func.cc:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_select.cc:
Auto merged
mysql-test/r/subselect.result:
Manual merge.
mysql-test/t/group_by.test:
Manual merge.
mysql-test/t/subselect.test:
Manual merge.
mysql-test/t/view.test:
Manual merge.
into linux-st28.site:/home/martin/mysql/src/bug31797/my51-bug31797-pushee
mysql-test/r/group_by.result:
Auto merged
mysql-test/t/group_by.test:
Auto merged
sql/item.cc:
Auto merged
The name resolution for correlated subqueries and HAVING clauses
failed to distinguish which of two was being performed when there
was a reference to an outer aliased field.
Fixed by adding the condition that HAVING clause name resulotion
is being performed.
mysql-test/r/group_by.result:
Bug#31797: Test result
mysql-test/t/group_by.test:
Bug#31797: Test case
sql/item.cc:
Bug#31797:
Corrected function comment.
The fix, raising the error is restricted to HAVING name resolution.
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 optimizer takes different execution paths during EXPLAIN than SELECT,
this fix relates only to EXPLAIN, hence no behavior changes.
The test of sort keys for ORDER BY was prohibited from considering keys
that were mentioned in IGNORE KEYS FOR ORDER BY. This led to two
inconsistencies: One was that IGNORE INDEX FOR GROUP BY and
IGNORE INDEX FOR ORDER BY gave apparently different EXPLAINs; the latter
erroneously claimed to do filesort. The second inconsistency
is that the test of sort keys is called twice, finding a sort key the first
time but not the second time, leading to the mentioned filesort.
Fixed by making the test of sort keys consider all enabled
keys on the table. This test rejects keys that are not covering, and for
covering keys the hint should be ignored anyway.
mysql-test/r/group_by.result:
Bug#30665: Changed test result. The plan gets more efficient here.
The output is included in order to show that it is still correct.
mysql-test/r/order_by.result:
Bug#30665: Test result
mysql-test/t/group_by.test:
Bug#30665: Changed test case to show correctness of changed plan
mysql-test/t/order_by.test:
Bug#30665: Test case
sql/sql_select.cc:
Bug#30665:
- the fix: Give test_if_skip_sort_order all keys not the subset of non-disabled keys.
- Added comment to test_if_skip_sort_order
and strategy (explain)
The fix for WL3527 adds tests that test if the index usage hints
combinations don't cause syntax errors.
The EXPLAIN for one of these tests can be affected by the size of the
rowid on the disk (affected by the presence of large file support).
Fixed to avoid the platform dependent test result by removing the
irrelevant columns from the EXPLAIN result.
mysql-test/r/group_by.result:
Bug #30393: ignore columns irrelevant to the test
mysql-test/t/group_by.test:
Bug #30393: ignore columns irrelevant to the test
The optimization that uses a unique index to remove GROUP BY did not
ensure that the index was actually used, thus violating the ORDER BY
that is implied by GROUP BY.
Fixed by replacing GROUP BY with ORDER BY if the GROUP BY clause contains
a unique index over non-nullable field(s). In case GROUP BY ... ORDER BY
null is used, GROUP BY is simply removed.
mysql-test/include/mix1.inc:
Bug#30596: Test case for InnoDB
Here, as opposed to for MyISAM, row lookup is done using index
whenever the index covers the group list.
mysql-test/r/distinct.result:
Bug#30596: Changed test case.
Prior to Bug#16458, These queries use temp table and filesort. The
bug was that they used a temp table. However, that patch removed
filesort also, in which case we can no longer gurantee correct ordering.
mysql-test/r/group_by.result:
Bug#30596: Correct result
The test case for IGNORE INDEX FOR GROUP BY gets degraded performance
(unneccesary filesort). This is due to Bug#30665, which will be fixed separately.
mysql-test/r/innodb_mysql.result:
Bug#30596: Test result
mysql-test/t/group_by.test:
Bug#30596: Test case
sql/sql_select.cc:
Bug#30596: The fix:
- replace GROUP BY with ORDER BY unless ORDER BY [NULL|<constant>]
- make sure to use the keys for GROUP BY in this ORDER BY.
The optimization that uses a unique index to remove GROUP BY, did not
ensure that the index was actually used, thus violating the ORDER BY
that is impled by GROUP BY.
Fixed by replacing GROUP BY with ORDER BY if the GROUP BY clause contains
a unique index. In case GROUP BY ... ORDER BY null is used, GROUP BY is
simply removed.
BitKeeper/etc/ignore:
Added support-files/mysqld_multi.server tests/bug25714 cscope.in.out cscope.out cscope.po.out to the ignore list
mysql-test/r/distinct.result:
Bug#30596: Changed test case.
Prior to Bug#16458, These queries use temp table and filesort. The
bug was that they used a temp table. However, that patch removed
filesort also, in which case we can no longer gurantee correct ordering.
mysql-test/r/group_by.result:
Bug#30596: Correct result
mysql-test/r/innodb_mysql.result:
Bug#30596: Test case for innodb. Here, as opposed to for MyISAM, row
lookup is done using index whenever the index covers the group list.
mysql-test/t/group_by.test:
Bug#30596: Test case
mysql-test/t/innodb_mysql.test:
Bug#30596: Test case
sql/sql_select.cc:
Bug#30596: The fix, replacing GROUP BY with ORDER BY unless
ORDER BY [NULL|<constant>]
into mysql.com:/home/hf/work/29717/my51-29717
mysql-test/r/group_by.result:
Auto merged
mysql-test/r/insert_select.result:
Auto merged
mysql-test/t/group_by.test:
Auto merged
mysql-test/t/insert_select.test:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_select.h:
Auto merged
SELECT statement itself returns empty.
As a result of this bug 'SELECT AGGREGATE_FUNCTION(fld) ... GROUP BY'
can return one row instead of an empty result set.
When GROUP BY only has fields of constant tables
(with a single row), the optimizer deletes the group_list.
After that we lose the information about whether we had an
GROUP BY statement. Though it's important
as SELECT min(x) from empty_table; and
SELECT min(x) from empty_table GROUP BY y; have to return
different results - the first query should return one row,
second - an empty result set.
So here we add the 'group_optimized_away' flag to remember this case
when GROUP BY exists in the query and is removed
by the optimizer, and check this flag in end_send_group()
mysql-test/r/group_by.result:
Bug #29717 INSERT INTO SELECT inserts values even if
SELECT statement itself returns empty.
test result
mysql-test/r/insert_select.result:
Bug #29717 INSERT INTO SELECT inserts values even if
SELECT statement itself returns empty.
test result
mysql-test/t/group_by.test:
Bug #29717 INSERT INTO SELECT inserts values even if
SELECT statement itself returns empty.
This is additional testcase that is more basic than the
original bug's testcase and has the same reason.
mysql-test/t/insert_select.test:
Bug #29717 INSERT INTO SELECT inserts values even if
SELECT statement itself returns empty.
test case
sql/sql_select.cc:
Bug #29717 INSERT INTO SELECT inserts values even if
SELECT statement itself returns empty.
Remember the 'GROUP BY was optimized away' case in the JOIN::group_optimized
and check this in the end_send_group()
sql/sql_select.h:
Bug #29717 INSERT INTO SELECT inserts values even if
SELECT statement itself returns empty.
JOIN::group_optimized member added to remember the 'GROUP BY optimied away'
case
