MDEV-24740: Selectivity for equi-join predicates not involed in ref access is not taken into account for join cardinality estimation
Introduced a new function to evaluate the selectivity for equi-join predicates
which are not part of ref access.
Enabled this calculation only when one can use the ORDER BY LIMIT optimization.
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.
Revert an accidental update of ColumnStore.
A different submodule is being used between MariaDB 10.5 and 10.6.
The submodule was accidentally updated to the 10.5 version in the merge.
fseg_page_is_free(): Because MDEV-24167 changed fil_space_t::latch
to a simple non-recursive rw-lock, we must avoid acquiring a shared
latch if the current thread already holds an exclusive latch.
This affects the test innodb.innodb_bug59733, which is exercising
the change buffer.
fil_space_t::is_owner(): Make available in non-debug builds.
