- When a JOIN has both "optimization tabs" (JOIN_TABs used to
read the base tables and do the join operation) and also
has "execution tabs" (a JOIN_TAB that is to produce result set
that is sent to the client), do not forget to call JOIN_TAB::cleanup()
for the execution JOIN_TAB.
This only happend when using an ORDER BY on a primary key part, where all other key parts where constant.
Remove of duplicated expressions in ORDER BY (as the old code did this in some strange cases)
mysql-test/r/group_by.result:
Fixed results to take into account that duplicate order by parts are now deleted
mysql-test/r/group_by_innodb.result:
Ensure extended keys are on
mysql-test/r/innodb_ext_key.result:
More tests
mysql-test/r/order_by.result:
More tests
mysql-test/t/group_by.test:
Fixed results to take into account that duplicate order by parts are now deleted
mysql-test/t/group_by_innodb.test:
Ensure extended keys are on
mysql-test/t/innodb_ext_key.test:
More tests
mysql-test/t/order_by.test:
More tests
sql/sql_select.cc:
Fixed bug where we looked at extended key parts when we shouldn't
Remove of duplicated expressions in ORDER BY
sql/table.cc:
Indentation fixes
The earlier pushed fix for the bug was incomplete. It did not remove
the main cause of the problem: the function remove_eq_conds()
removed always true multiple equalities from any conjunct, but did not
adjust the list of them stored in Item_cond_and::cond_equal.current_level.
Simplified the test case for the bug and moved it to another test file.
The fix triggered changes in EXPLAIN EXTENDED for some queries.
- Don't pull out a table out of a semi-join if it is on the inner side of an outer join.
- Make join->sort_by_table= get_sort_by_table(...) call after const table detection
is done. That way, the value of join->sort_by_table will match the actual execution.
Which will allow the code in setup_semijoin_dups_elimination() (search for
"Make sure that possible sorting of rows from the head table is not to be employed."
to see that "Using filesort" is going to be used together with Duplicate Elimination (
and change it to Using temporary + Using filesort)
- make_join_readinfo() has the code that forces use of "Using temporary;
Using filesort" when join buffering is in use.
That code didn't handle all cases, in particular it didn't hande the case
where ORDER BY originally has tables from multiple columns, but the
optimizer eventually figures out that doing filesort() on one table
will be sufficient. Adjusted the code to handle that case.
Apply fix suggested by Igor:
- When eliminate_item_equal() generates pair-wise equalities from a
multi-equality, do generate a "bridge" equality between the first
field inside SJM nest and the field that's first in the overall multi-equality.
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.
MDEV-5034:Wrong result on LEFT JOIN with a SELECT SQ or a merge view, UNION in IN subquery
Make reset null_row same as it was set in evaluate_null_complemented_join_record().
The problem was that view firlds detect null_row by not-yet-reset table.
The bug caused a memory overwrite in the function update_ref_and_keys()
It happened due to a wrong value of SELECT_LEX::cond_count. This value
historically was calculated by the fix_fields method. Now the logic of
calling this method became too complicated and, as a result, this value
is calculated not always correctly.
The patch changes the way how and when the values of SELECT_LEX::cond_count
and of SELECT_LEX::between_count are calculated. The new code does it just at
the beginning of update_ref_and_keys().
Apparently in a general case a short-cut for the distinct optimization
is invalid if join buffers are used to join tables after the tables whose
values are to selected.
Other fix of maybe_null problem and revert of revno: 3608 "MDEV-3873 & MDEV-3876 & MDEV-3912 : Wrong result (extra rows) with ALL subquery from a MERGE view."
* add TokuDB, together with the ft-index library
* cmake support, auto-detecting whether tokudb can be built
* fix packaging - tokudb-engine.rpm, deb
* remove PBXT
* add jemalloc
* the server is built with jemalloc by default even if TokuDB is not built
* documentation files in RPM are installed in the correct location
* support for optional deb packages (tokudb has specific build requirements)
* move plugins from mariadb-server deb to appropriate debs (server/test/libmariadbclient)
* correct mariadb-test.deb to be not architecture-independent
* fix out-of-tree builds to never modify in-tree files
* new handler::prepare_index_scan() method
ORDER BY does not work
Use "dynamic" row format (instead of "block") for MARIA internal
temporary tables created for cursors.
With "block" row format MARIA may shuffle rows, with "dynamic" row
format records are inserted sequentially (there are no gaps in data
file while we fill temporary tables).
This is needed to preserve row order when scanning materialized cursors.
When a non-nullable datetime field is used under an IS NULL predicate
of the WHERE condition in a query with outer joins the remove_eq_conds
function should check whether this field belongs to an inner table
of any outer join that can be, in a general case, a nested outer join.
When in function remove_eq_conds() a sub-formula of the processed condition
is replaced for another formula we should ensure that in the resulting
formula AND/OR levels must alternate.
The patch to fix mdev-4418 turned out to be incorrect.
At the substitution of single row tables in make_join_statistics()
the used multiple equalities may change and references to the new multiple
equalities must be updated. The function remove_eq_conds() takes care of it and
it should be called right after the substitution of single row tables.
Calling it after the call of make_join_statistics was a mistake.
