database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2026-01-06 05:22:24 +03:00
Code Activity

Fix bug#11482 4.1.12 produces different resultset for a complex query

Browse Source 
than in previous 4.1.x

Wrongly applied optimization were adding NOT NULL constraint which results in
rejecting valid rows and reduced result set.

The problem was that add_notnull_conds() while checking subquery were adding
NOT NULL constraint to left joined table, to which, normally, optimization 
don't have to be applied.


sql/sql_select.cc:
  Fix bug #11482 Wrongly applied optimization was erroneously rejecting valid rows
  Constraint were added to optimization appliance test.
mysql-test/t/select.test:
  Test case for bug #11482  Wrongly applied optimization was erroneously rejecting valid rows
mysql-test/r/select.result:
  Test case for bug #11482  Wrongly applied optimization was erroneously rejecting valid rows
This commit is contained in:
unknown
2005-07-16 03:29:12 +04:00
parent dba3190474
commit 0f41fb4234
3 changed files with 41 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
sql/sql_select.cc
View File

@@ -3508,7 +3508,23 @@ inline void add_cond_and_fix(Item **e1, Item *e2)
(where othertbl is a non-const table and othertbl.field may be NULL)
and add them to conditions on correspoding tables (othertbl in this
example).
Exception from that is the case when referred_tab->join != join.
I.e. don't add NOT NULL constraints from any embedded subquery.
Consider this query:
SELECT A.f2 FROM t1 LEFT JOIN t2 A ON A.f2 = f1
WHERE A.f3=(SELECT MIN(f3) FROM t2 C WHERE A.f4 = C.f4) OR A.f3 IS NULL;
Here condition A.f3 IS NOT NULL is going to be added to the WHERE
condition of the embedding query.
Another example:
SELECT * FROM t10, t11 WHERE (t10.a < 10 OR t10.a IS NULL)
AND t11.b <=> t10.b AND (t11.a = (SELECT MAX(a) FROM t12
WHERE t12.b = t10.a ));
Here condition t10.a IS NOT NULL is going to be added.
In both cases addition of NOT NULL condition will erroneously reject
some rows of the result set.
referred_tab->join != join constraint would disallow such additions.
This optimization doesn't affect the choices that ref, range, or join
optimizer make. This was intentional because this was added after 4.1
was GA.
@@ -3539,6 +3555,8 @@ static void add_not_null_conds(JOIN *join)
DBUG_ASSERT(item->type() == Item::FIELD_ITEM);
Item_field *not_null_item= (Item_field*)item;
JOIN_TAB *referred_tab= not_null_item->field->table->reginfo.join_tab;
if (referred_tab->join != join)
continue;
Item *notnull;
if (!(notnull= new Item_func_isnotnull(not_null_item)))
DBUG_VOID_RETURN;