MDEV-20501: Assertion `maybe_null || !null_value' failed in Item_func_round::date_op
When the optimizer finds a constant (or system) table $TBL which is empty
or has no matching row, it would set table->null_row=true. This is done
even for tables with table->maybe_null==0.
Then, it would proceed to perform query optimization phases (what for?)
which will attempt to evaluate Item expressions referring to $TBL.
Eventually some Item expression will get the value of $TBL.not_null_field,
get SQL NULL and fail an assertion.
Fixed by not performing any query optimization steps after we've got
constant/empty tables with no matching rows.
Test result changes contain a lot of changes like
- ... Impossible WHERE noticed after reading const tables
+ ... Const row not found
as well as other changes caused by slightly-different processing of
the special case of empty constant tables.
MDEV-30218: Incorrect optimization for rowid_filtering
Patch from Igor Babaev:
- Revert the changes in commit 87eccd
- Instead:
- When considering rowid filter with eq_ref access,
assume the cost of index-only eq_ref scan is 50% of
non-index-only eq_ref scan.
- For other kinds of keys: Cap the cost of index-only read estimate
to the cost of non-index-only read estimate. This is to fix cost
model inconsistencies where cost of index-only estimate ends up
being higher.
- When considering rowid filter with range access, do not forget to
multiply quick_index_only_costs[key_no] by record_count.
MDEV-21187: log_slow_filter="" logs queries not using indexes
Consistent with MDEV-4206 and empty log_slow_filter still means
no explict filtering. Since 21518ab2e453 however the
log_queries_not_using_indexes became stored in the same variable.
As we need to test for the absense of log_queries_not_using_indexes
the SERVER_QUERY_NO_INDEX USED part of log_slow_statement, the empty
criteria resulted in an always true to log queries not using indexes if
log_slow_filter was set to empty.
Adjusted the log_slow.test for MDEV-4206 as slow_log_query has been
global and session for a while and it was relying on the MDEV-21187
buggy behavior to detect a slow query.
MDEV-30218: Incorrect optimization for rowid_filtering
(Patch from Monty, slightly amended)
Fix rowid filtering optimization in best_access_path():
== Ref access + rowid filtering ==
The cost computations compare #records and index-only scan cost
(keyread_tmp) to find out the per-record advantage one will get if
they skip reading full table record.
The computations produce wrong result when:
- the #records are "clipped down" with s->worst_seeks or
thd->variables.max_seeks_for_key. keyread_tmp is not clipped
this way so the numbers are not comparable.
- access_factor is negative. This means index_only read is
cheaper than non-index-only read.
This patch makes the optimizer not to consider Rowid Filtering in
such cases.
The decision is logged in the Optimizer Trace using
"rowid_filter_skipped" name.
== Range access + rowid filtering ==
when considering to use Rowid Filter with range access, do multiply
keyread_tmp by record_count. That way, it is comparable with the
range access's estimate, which is multiplied by record_count.
MDEV-30065: mariadb-install-db allow for --enforce-storage-engine=InnoDB
Hide the errors related to missing innodb stats tables in bootstrap mode
on the assumption that because we are in bootstrap mode they are going
to be created.
