Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-590

LP:885799 - No "Impossible WHERE" for false constant conds when expensive const cond is present

Details

    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)

      Attachments

        Activity

          Launchpad bug id: 885799

          ratzpo Rasmus Johansson (Inactive) added a comment - Launchpad bug id: 885799

          Fixed in 5.5.31 - MDEV-4144

          pomyk Patryk Pomykalski added a comment - Fixed in 5.5.31 - MDEV-4144

          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.

          elenst Elena Stepanova added a comment - 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.

          People

            Unassigned Unassigned
            psergei Sergei Petrunia
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.