From bfa9c2cf2d325560b80c947ecb6850390cfe8bb8 Mon Sep 17 00:00:00 2001 From: qiancai Date: Wed, 8 Nov 2023 15:17:30 +0800 Subject: [PATCH 1/3] fix the operator info --- correlated-subquery-optimization.md | 2 +- explain-subqueries.md | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/correlated-subquery-optimization.md b/correlated-subquery-optimization.md index 1477dfe06f48f..08c753be17775 100644 --- a/correlated-subquery-optimization.md +++ b/correlated-subquery-optimization.md @@ -100,4 +100,4 @@ explain select * from t1 where t1.a < (select sum(t2.a) from t2 where t2.b = t1. +------------------------------------------+-----------+-----------+------------------------+--------------------------------------------------------------------------------------+ ``` -After disabling the subquery decorrelation rule, you can see `range: decided by [eq(test.t2.b, test.t1.b)]` in `operator info` of `IndexRangeScan_25(Build)`. It means that the decorrelation of correlated subquery is not performed and TiDB uses the index range query. +After disabling the subquery decorrelation rule, you can see `range: decided by [eq(test.t2.b, test.t1.b)]` in `operator info` of `IndexRangeScan_42(Build)`. It means that the decorrelation of correlated subquery is not performed and TiDB uses the index range query. diff --git a/explain-subqueries.md b/explain-subqueries.md index 7558e01f67155..a7f3f48ed0064 100644 --- a/explain-subqueries.md +++ b/explain-subqueries.md @@ -69,9 +69,9 @@ EXPLAIN SELECT * FROM t1 WHERE id IN (SELECT t1_id FROM t2); From the query results above, you can see that TiDB uses the index join operation `| IndexJoin_14` to join and transform the subquery. In the execution plan, the execution process is as follows: -1. The index scanning operator `└─IndexFullScan_31` at the TiKV side reads the values of the `t2.t1_id` column. -2. Some tasks of the `└─StreamAgg_39` operator deduplicate the values of `t1_id` in TiKV. -3. Some tasks of the `├─StreamAgg_49(Build)` operator deduplicate the values of `t1_id` in TiDB. The deduplication is performed by the aggregate function `firstrow(test.t2.t1_id)`. +1. The index scanning operator `└─IndexFullScan_26` at the TiKV side reads the values of the `t2.t1_id` column. +2. Some tasks of the `└─StreamAgg_34` operator deduplicate the values of `t1_id` in TiKV. +3. Some tasks of the `├─StreamAgg_44(Build)` operator deduplicate the values of `t1_id` in TiDB. The deduplication is performed by the aggregate function `firstrow(test.t2.t1_id)`. 4. The operation results are joined with the primary key of the `t1` table. The join condition is `eq(test.t1.id, test.t2.t1_id)`. ## Inner join (unique subquery) From 42c82cfbe30c1118ac9b1345c53dbecf680a36df Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Wed, 8 Nov 2023 16:03:41 +0800 Subject: [PATCH 2/3] Update explain-subqueries.md --- explain-subqueries.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/explain-subqueries.md b/explain-subqueries.md index a7f3f48ed0064..f9a4321f786b3 100644 --- a/explain-subqueries.md +++ b/explain-subqueries.md @@ -67,7 +67,7 @@ EXPLAIN SELECT * FROM t1 WHERE id IN (SELECT t1_id FROM t2); +--------------------------------+----------+-----------+------------------------------+---------------------------------------------------------------------------------------------------------------------------+ ``` -From the query results above, you can see that TiDB uses the index join operation `| IndexJoin_14` to join and transform the subquery. In the execution plan, the execution process is as follows: +From the query results above, you can see that TiDB uses the index join operation `| IndexJoin_15` to join and transform the subquery. In the execution plan, the execution process is as follows: 1. The index scanning operator `└─IndexFullScan_26` at the TiKV side reads the values of the `t2.t1_id` column. 2. Some tasks of the `└─StreamAgg_34` operator deduplicate the values of `t1_id` in TiKV. From b45361447cdf9bdf1ba3651f7ceb9b2eb5787871 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Wed, 8 Nov 2023 16:10:00 +0800 Subject: [PATCH 3/3] Update explain-subqueries.md Co-authored-by: Zhou Kunqin <25057648+time-and-fate@users.noreply.github.com> --- explain-subqueries.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/explain-subqueries.md b/explain-subqueries.md index f9a4321f786b3..5b7c08a4f5154 100644 --- a/explain-subqueries.md +++ b/explain-subqueries.md @@ -67,7 +67,7 @@ EXPLAIN SELECT * FROM t1 WHERE id IN (SELECT t1_id FROM t2); +--------------------------------+----------+-----------+------------------------------+---------------------------------------------------------------------------------------------------------------------------+ ``` -From the query results above, you can see that TiDB uses the index join operation `| IndexJoin_15` to join and transform the subquery. In the execution plan, the execution process is as follows: +From the query results above, you can see that TiDB uses the index join operation `IndexJoin_15` to join and transform the subquery. In the execution plan, the execution process is as follows: 1. The index scanning operator `└─IndexFullScan_26` at the TiKV side reads the values of the `t2.t1_id` column. 2. Some tasks of the `└─StreamAgg_34` operator deduplicate the values of `t1_id` in TiKV.