MDEV-22360: Sufficient conditions for accurate calculation of join cardinality
The aim of this task is to check if the estimate of join cardinality are accurate or not.
The implementation to check if we have the accurate estimate of the join cardinality is a
simple one, we have to walk over the WHERE clause.
The approach can be broken into 2 cases:
Case 1: WHERE clause is an AND conjunct
For an AND item at the top level, we need to walk over all the top level conjuncts and call walk
individually on them. This is done in such a way because for an AND conjunct at the top
level we may have accurate selectivity, even if the predicate belongs to a different column.
Eg: t1.a > 10 and t2.a < 5.
For this AND item we will have accurate selectivities.
For AND conjuncts (not at the top level), the entire conjunct needs to be resolved to one column.
Eg: t1.a = t2.a AND ( (t1.a > 5 AND t2.a < 10) OR t1.a <= 0)
Case 2:
2a) OR item
For an OR item at the top level, we need to make sure that all the columns inside the OR
conjunct need to belong to one column directly or indirectly.
This needs to happen for an OR conjunct even if it is not at the
top level.
Eg: (t1.a > 5 or t1.a < 0);
2b) Single predicate at the top level
Eg:
t1.a= t2.a [ For this case we need to make sure we know number of distinct values for t1.a and t2.a ]
t1.a > 5 [ sargable predicate, get the estimate from the range optimizer ]
We need to make sure that for the predicates in the WHERE clause we have estimates either
from the first component of the index or from the EITS.
The implementation of these is covered with the callback
function passed to walk function.
MDEV-24101 innodb_random_read_ahead=ON causes hang on DDL or shutdown
buf_read_ahead_random(): Do not leak a tablespace reference.
The reference was already acquired in fil_space_t::get(),
and we must only check that operations were not stopped.
This error was introduced when
commit 118e258aaac5da75a2ac4556201aaea3688fac67
merged n_pending_ios, n_pending_ops into a single n_pending.
This was not noticed earlier, because innodb_random_read_ahead
is OFF by default and our regression tests did not vary that
parameter at all.
