Commit 724ab9a1 authored by Varun Gupta's avatar Varun Gupta

MDEV-16057: Using optimization Splitting with Group BY we see an unnecessary attached condition

            t1.pk IS NOT NULL where pk is a PRIMARY KEY

For equalites in the WHERE clause we create a keyuse array that contains the set of all equalities.
For each KEYUSE inside the keyuse array we have a field "null_rejecting"
which tells that the equality will not hold if either the left or right
hand side of the equality is NULL.
If the equality is NULL rejecting then we accordingly add a NOT NULL condition for the field present in
the item val(present in the KEYUSE struct) when we are doing ref access.

For the optimization of splitting with GROUP BY we always set the null_rejecting to TRUE and we are doing ref access on
the GROUP by field. This does create a problem when the equality is NOT NULL rejecting. This happens in this case as
in the equality we have the right hand side as t1.pk where pk is a PRIMARY KEY , hence it is NOT NULLABLE. So we should have
null rejecting set to FALSE for such a case.
parent 0bfd45f6
......@@ -15071,7 +15071,6 @@ EXPLAIN
"materialized": {
"query_block": {
"select_id": 2,
"outer_ref_condition": "t1.pk1 is not null",
"table": {
"table_name": "t2",
"access_type": "eq_ref",
......
......@@ -544,7 +544,14 @@ void TABLE::add_splitting_info_for_key_field(KEY_FIELD *key_field)
added_key_field->level= 0;
added_key_field->optimize= KEY_OPTIMIZE_EQ;
added_key_field->eq_func= true;
added_key_field->null_rejecting= true;
Item *real= key_field->val->real_item();
if ((real->type() == Item::FIELD_ITEM) &&
((Item_field*)real)->field->maybe_null())
added_key_field->null_rejecting= true;
else
added_key_field->null_rejecting= false;
added_key_field->cond_guard= NULL;
added_key_field->sj_pred_no= UINT_MAX;
return;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment