[MDEV-590] LP:885799 - No "Impossible WHERE" for false constant conds when expensive const cond is present Created: 2011-11-03  Updated: 2014-04-11  Resolved: 2014-04-11

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: None
Fix Version/s: 5.5.36, 10.0.9, 5.3.13

Type: Bug Priority: Minor
Reporter: Sergei Petrunia Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: Launchpad

Attachments: XML File LPexportBug885799.xml    

 Description   

If we have a query which has

  • regular ("cheap") constant condition that evaluates to FALSE
  • an expensive constant condition (doesn't matter what it evaluates to)
    then "Impossible WHERE" will not be generated.

Example:

create table t1 (a int);
insert into t1 values (1),(2),(3);
 
create table t2 as select * from t1;
 
create table t_pk1 (a int primary key);
create table t_pk2 (a int primary key);
 
insert into t_pk1 select a from t1;
insert into t_pk2 select a from t1;
 
alter table t_pk1 add b int;
alter table t_pk2 add b int;

## Here t_pk1 is a constant table, and "t_pk1.b> 3" is a cheap constant condition that evaluates to FALSE:
 
MariaDB [j10]> explain select * from t_pk1, t2 where t_pk1.a=2 and t_pk1.b> 3 ;
+----+-------------+-------+------+---------------+------+---------+------+------+-----------------------------------------------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra                                               |
+----+-------------+-------+------+---------------+------+---------+------+------+-----------------------------------------------------+
|  1 | SIMPLE      | NULL  | NULL | NULL          | NULL | NULL    | NULL | NULL | Impossible WHERE noticed after reading const tables |
+----+-------------+-------+------+---------------+------+---------+------+------+-----------------------------------------------------+
1 row in set (0.00 sec)

# Now, let's add an expensive constant condition, and observe that we won't be getting "Impossible WHERE" anymore:
 
MariaDB [j10]> explain select * from t_pk1, t2 where t_pk1.a=2 and t_pk1.b> 3 and 2 > (select max(a) from t1);
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref   | rows | Extra |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
|  1 | PRIMARY     | t_pk1 | const | PRIMARY       | PRIMARY | 4       | const |    1 |       |
|  1 | PRIMARY     | t2    | ALL   | NULL          | NULL    | NULL    | NULL  |    3 |       |
|  2 | SUBQUERY    | t1    | ALL   | NULL          | NULL    | NULL    | NULL  |    3 |       |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
3 rows in set (0.00 sec)



 Comments   
Comment by Rasmus Johansson (Inactive) [ 2011-11-03 ]

Launchpad bug id: 885799

Comment by Patryk Pomykalski [ 2013-06-14 ]

Fixed in 5.5.31 - MDEV-4144

Comment by Elena Stepanova [ 2014-04-11 ]

The problem disappeared from 5.3 tree with the following revision:

revno: 3765
revision-id: igor@askmonty.org-20140221052733-ypg4dpfcmy5l0b3q
parent: psergey@askmonty.org-20140219143412-rp3flx1pmhw6zawn
committer: Igor Babaev <igor@askmonty.org>
branch nick: maria-5.3
timestamp: Thu 2014-02-20 21:27:33 -0800
message:
  After constant row substitution the optimizer should call the method
  update_used_tables for the the where condition to update cached
  indicators of constant subexpressions. It should be done before further
  possible simplification of the where condition.
  
  This change caused simplification of the executed where conditions 
  in many test cases.

Generated at Thu Feb 08 06:29:53 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.