pingcap/tidb

some OR condition can be pushed down to the leaves of the JOIN

Open

#35 261 ouverte le 9 juin 2022

Voir sur GitHub
 (3 commentaires) (0 réactions) (2 assignés)Go (6 186 forks)batch import
help wantedsig/plannertype/enhancement

Métriques du dépôt

Stars
 (40 090 stars)
Métriques de merge PR
 (Merge moyen 14j 4h) (346 PRs mergées en 30 j)

Description

Enhancement

Consider the following SQL

explain select * from t join t1 on t.id = t1.id join t2 on t.id = t2.id where t.b = 1 or t1.a = 2 or t2.b = 3;
mysql> explain select * from t join t1 on t.id = t1.id join t2 on t.id = t2.id where t.b = 1 or t1.a = 2 or t2.b = 3;
+-------------------------------+----------+-----------+---------------+------------------------------------------------------------------------------------------------------------------------------------------------+
| id                            | estRows  | task      | access object | operator info                                                                                                                                  |
+-------------------------------+----------+-----------+---------------+------------------------------------------------------------------------------------------------------------------------------------------------+
| HashJoin_24                   | 15625.00 | root      |               | inner join, equal:[eq(jingyocar.t.id, jingyocar.t2.id)], other cond:or(eq(jingyocar.t.b, 1), or(eq(jingyocar.t1.a, 2), eq(jingyocar.t2.b, 3))) |
| ├─TableReader_68(Build)       | 10000.00 | root      |               | data:TableFullScan_67                                                                                                                          |
| │ └─TableFullScan_67          | 10000.00 | cop[tikv] | table:t2      | keep order:false, stats:pseudo                                                                                                                 |
| └─MergeJoin_42(Probe)         | 12500.00 | root      |               | inner join, left key:jingyocar.t.id, right key:jingyocar.t1.id                                                                               |
|   ├─TableReader_39(Build)     | 10000.00 | root      |               | data:TableFullScan_38                                                                                                                          |
|   │ └─TableFullScan_38        | 10000.00 | cop[tikv] | table:t1      | keep order:true, stats:pseudo                                                                                                                  |
|   └─TableReader_37(Probe)     | 10000.00 | root      |               | data:TableFullScan_36                                                                                                                          |
|     └─TableFullScan_36        | 10000.00 | cop[tikv] | table:t       | keep order:true, stats:pseudo                                                                                                                  |
+-------------------------------+----------+-----------+---------------+------------------------------------------------------------------------------------------------------------------------------------------------+

As you can see, in the current execution plan, the OR condition is blocked at the top of the join node. But actually, if we push the OR condition into the table t side, the condition can actually be transformed to t.b = 1 or false or false => t.b = 1. If we push it to the t1 side, we get false or t1.a = 2 or false => t1.a = 2. If we push it to the t2 side, we get false or false or t2.b=3 => t2.b=3. This indicates that we can split the OR condition and push each part to the place where need it.

Guide contributeur