BNL and BNLH joins pre-filter the records from a joined table via JOIN_TAB::cache_select->cond.
There is no need to re-evaluate the same conditions via JOIN_TAB::select_cond. This patch removes
the duplicated conditions from the top-level conjuncts of each pushed condition.
The added "Using where" in few EXPLAINs is due to taking into account tab->cache_select->cond
in addition to tab->select_cond in JOIN::save_explain_data_intern.
depends on uninitialised value(s) in JOIN::save_explain_data_intern"
- Make find_best() /* the old join optimizer code */ also use table
condition selectivity.
- It turns out, there are statements that will call lex_start(thd->lex)
after parsing has been finished. lex_start() will set lex->explain=NULL,
which will lose the pointer to already allocated Explain_plan object.
- To get rid of this, switch to lazy creation of lex->explain. Now, it is
created only when we get a part ot query plan.
Update the SHOW EXPLAIN code to work with the
new architecture (part#1):
Before, SHOW EXPLAIN operated on real query plan structures,
which meant it had to check when SELECTs are created/deleted.
SELECTs would call apc_target->enable() when they got a query
plan and disable() when their query plan was deleted.
Now, Explain data structure becomes available at once (and we
call apc_target->enable()) and then it stays until it is deleted
(when that happens, we call apc_target->disable()).
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.
- Make EXPLAIN UPDATE/DELETE work inside SPs
- Return correct error code from mysql_delete()
- EXPLAIN <multi-DELETE> will create a multi_delete object (as it
affects the optimization). select_result will be only used for
producing EXPLAIN output.
- Query plan footprint (in new terms, "EXPLAIN structure") should always keep
a copy of key_name. This is because the table might be a temporary table which
may be already freed by the time we use query plan footprint.
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."
- Make QPF structures store data members, not strings.
This is not fully possible, because table names (and hence
key names, etc) can be deleted, and we have to store strings.
* 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.
