pingcap / pingcap/tidb

short-circuit in SELECT OR/AND clause

Open
#62,134 0 comments 0 reactions 1 assignee Claimed by @hawkingrei View on GitHub
severity/moderate sig/planner type/enhancement
Dominant language
Go
Stars
40.5k
Forks
6.2k
PR merge metrics
PR metrics pending

Description

## Bug Report

Hi, TiDB developers, please consider such queries:
```sql
SELECT TRUE OR (SELECT COUNT(*) FROM t1)>1;
SELECT FALSE AND (SELECT COUNT(*) FROM t1)>1;
```
For the first query, there are two conditions in the `WHERE` clause, connected by `OR`, which means that if any one of the conditions is met, it is `TRUE`. Therefore, when we calculate two conditions, if we calculate one of the conditions to be `TRUE`, we can short-circuit the `OR` expressions, which can avoid unnecessary calculations. For the second query, similarly, if we calculate one of the conditions to be `FALSE`, we can short-circuit the `AND` expressions. However, TiDB does not short-circuit to optimize such queries. Especially, short-circuiting is necessary when the computation of the condition is expensive.

### 1. Minimal reproduce step

(1) Create table and insert data
```sql
CREATE TABLE t1(c1 INT8);

CREATE TEMPORARY TABLE digits (d INT);
INSERT INTO digits VALUES (0),(1),(2),(3),(4),(5),(6),(7),(8),(9);

-- insert into t1 with 10 million rows
INSERT INTO t1
SELECT
d1.d + d2.d*10 + d3.d*100 + d4.d*1000 + d5.d*10000 + d6.d*100000 + d7.d*1000000 AS num
FROM
digits d1, digits d2, digits d3, digits d4, digits d5, digits d6, digits d7
WHERE
d1.d + d2.d*10 + d3.d*100 + d4.d*1000 + d5.d*10000 + d6.d*100000 + d7.d*1000000 <= 10000000;
```
(2) Execute query
```sql
SELECT TRUE OR (SELECT COUNT(c1) FROM t1)>1;
+------------------------------------+
| TRUE OR (SELECT COUNT(c1) FROM t1)>1 |
+------------------------------------+
| 1 |
+------------------------------------+
1 row in set (1.43 sec)

SELECT TRUE;
+------+
| TRUE |
+------+
| 1 |
+------+
1 row in set (0.00 sec)

SELECT FALSE AND (SELECT COUNT(c1) FROM t1)>1;
+--------------------------------------+
| FALSE AND (SELECT COUNT(c1) FROM t1)>1 |
+--------------------------------------+
| 0 |
+--------------------------------------+
1 row in set (1.43 sec)

SELECT FALSE;
+-------+
| FALSE |
+-------+
| 0 |
+-------+
1 row in set (0.00 sec)
```
The following case is more obvious. All of the four queries trigger `ERROR 8175 (HY000)`. Especially, their `EXPLAIN` statements perform actual execution.
```sql
SELECT TRUE OR (SELECT COUNT(*) FROM t1 a, t1 b)>1;
SELECT FALSE AND (SELECT COUNT(*) FROM t1 a, t1 b)>1;
EXPLAIN SELECT TRUE OR (SELECT COUNT(*) FROM t1 a, t1 b)>1;
EXPLAIN SELECT TRUE OR (SELECT COUNT(*) FROM t1 a, t1 b)>1;
ERROR 8175 (HY000): Your query has been cancelled due to exceeding the allowed memory limit for a single SQL query. Please try narrowing your query scope or increase the tidb_mem_quota_query limit and try again.[conn=2378170378]
```
### 2. What did you expect to see?
`SELECT OR/AND` clause could short-circuit, and `EXPLAIN` statements do not perform actual execution.
```sql
SELECT TRUE OR (SELECT COUNT(c1) FROM t1)>1;
+------------------------------------+
| TRUE OR (SELECT COUNT(c1) FROM t1)>1 |
+------------------------------------+
| 1 |
+------------------------------------+
1 row in set (0.00 sec)

SELECT FALSE AND (SELECT COUNT(c1) FROM t1)>1;
+--------------------------------------+
| FALSE AND (SELECT COUNT(c1) FROM t1)>1 |
+--------------------------------------+
| 0 |
+--------------------------------------+
1 row in set (0.00 sec)
```

### 3. What is your TiDB version? (Required)
| Release Version: v8.5.2
Edition: Community
Git Commit Hash: f43a13324440f92209e2a9f04c1bbe9cf763978d
Git Branch: HEAD
UTC Build Time: 2025-05-29 03:30:55
GoVersion: go1.23.8
Race Enabled: false
Check Table Before Drop: false
Store: tikv |

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.