From 1d3c89c566850a6ff417c5fcaafad251fd2367c7 Mon Sep 17 00:00:00 2001 From: lzmhhh123 Date: Mon, 29 Jun 2020 17:01:00 +0800 Subject: [PATCH 01/17] docs: add the predicates-push-down.md --- TOC.md | 1 + predicates-push-down.md | 151 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 152 insertions(+) create mode 100644 predicates-push-down.md diff --git a/TOC.md b/TOC.md index d06064b0dbab1..967b11547ed7e 100644 --- a/TOC.md +++ b/TOC.md @@ -99,6 +99,7 @@ + SQL Optimization + [SQL Optimization Process](/sql-optimization-concepts.md) + Logic Optimization + + [Predicates Push Down](predicates-push-down.md) + [Join Reorder](/join-reorder.md) + Physical Optimization + [Statistics](/statistics.md) diff --git a/predicates-push-down.md b/predicates-push-down.md new file mode 100644 index 0000000000000..fbeb952ed7761 --- /dev/null +++ b/predicates-push-down.md @@ -0,0 +1,151 @@ +--- +title: Predicates Push Down +category: reference +aliases: ['/docs/dev/predicates-push-down.md/','/docs/dev/reference/performance/predicates-push-down/'] +--- + +# Predicates Push Down(PPD) + +This document introduces one of the TiDB's logic optimization rules—Predicate Push Down(PPD). It aims to help readers understand the predicate push down and know its suitable and unsuitable scenarios. + +PPD pushes down selection operators as close to data source as possible to complete data filtering as early as possible. Thereby significantly reducing the cost of data transmission or computation. + +## Examples + +The following cases describes the optimization of PPD. Examples 1, 2, and 3 are cases where PPD is applicable, and examples 4, 5, and 6 are cases where PPD is not applicable. + +### Case 1: push predicates to storage layer + +```sql +create table t(id int primary key, a int); +explain select * from t where a < 1; ++-------------------------+----------+-----------+---------------+--------------------------------+ +| id | estRows | task | access object | operator info | ++-------------------------+----------+-----------+---------------+--------------------------------+ +| TableReader_7 | 3323.33 | root | | data:Selection_6 | +| └─Selection_6 | 3323.33 | cop[tikv] | | lt(test.t.a, 1) | +| └─TableFullScan_5 | 10000.00 | cop[tikv] | table:t | keep order:false, stats:pseudo | ++-------------------------+----------+-----------+---------------+--------------------------------+ +3 rows in set (0.00 sec) +``` + +In this query，pushing down the predicate `a < 1` on TiKV to filter the data can reduce the overhead caused by network transmission. + +### Case 1: push predicates to storage layer + +```sql +create table t(id int primary key, a int not null); +explain select * from t where a < substring('123', 1, 1); ++-------------------------+----------+-----------+---------------+--------------------------------+ +| id | estRows | task | access object | operator info | ++-------------------------+----------+-----------+---------------+--------------------------------+ +| TableReader_7 | 3323.33 | root | | data:Selection_6 | +| └─Selection_6 | 3323.33 | cop[tikv] | | lt(test.t.a, 1) | +| └─TableFullScan_5 | 10000.00 | cop[tikv] | table:t | keep order:false, stats:pseudo | ++-------------------------+----------+-----------+---------------+--------------------------------+ +``` + +This query has the same execution plan as the query in case 1, because the input parameters of the `substring` of the predicate `a < substring('123', 1, 1)` are constants, so they can be calculated in advance. Then simplify to get the equivalent predicate `a < 1`. Further, TiDB can push `a < 1` down to TiKV. + +### Case 3: push predicates below join operator + +```sql +create table t(id int primary key, a int not null); +create table s(id int primary key, a int not null); +explain select * from t join s on t.a = s.a where t.a < 1; ++------------------------------+----------+-----------+---------------+--------------------------------------------+ +| id | estRows | task | access object | operator info | ++------------------------------+----------+-----------+---------------+--------------------------------------------+ +| HashJoin_8 | 4154.17 | root | | inner join, equal:[eq(test.t.a, test.s.a)] | +| ├─TableReader_15(Build) | 3323.33 | root | | data:Selection_14 | +| │ └─Selection_14 | 3323.33 | cop[tikv] | | lt(test.s.a, 1) | +| │ └─TableFullScan_13 | 10000.00 | cop[tikv] | table:s | keep order:false, stats:pseudo | +| └─TableReader_12(Probe) | 3323.33 | root | | data:Selection_11 | +| └─Selection_11 | 3323.33 | cop[tikv] | | lt(test.t.a, 1) | +| └─TableFullScan_10 | 10000.00 | cop[tikv] | table:t | keep order:false, stats:pseudo | ++------------------------------+----------+-----------+---------------+--------------------------------------------+ +7 rows in set (0.00 sec) +``` + +In this query, the predicate `t.a < 1` is pushed below join to filter in advance, which can reduce the calculation of join. + +In addition，This SQL executes an inner join, and the `ON` condition is `t.a = s.a`. The predicate `s.a <1` can be derived from `t.a < 1` and pushed down to `s` table below the join operator. Filtering the `s` table can further reduce the calculation of join. + +### Case 4: predicates that are not supported by storage layers cannot be pushed down + +```sql +create table t(id int primary key, a int not null); +desc select * from t where substring('123', a, 1) = '1'; ++-------------------------+---------+-----------+---------------+----------------------------------------+ +| id | estRows | task | access object | operator info | ++-------------------------+---------+-----------+---------------+----------------------------------------+ +| Selection_7 | 2.00 | root | | eq(substring("123", test.t.a, 1), "1") | +| └─TableReader_6 | 2.00 | root | | data:TableFullScan_5 | +| └─TableFullScan_5 | 2.00 | cop[tikv] | table:t | keep order:false, stats:pseudo | ++-------------------------+---------+-----------+---------------+----------------------------------------+ +``` + +In this query, there is a predicate `substring('123', a, 1) = '1'`. + +From the `explain` results, we can see that the predicate is not pushed down to TiKV for calculation. This is because the TiKV coprocessor does not support the built-in function `substring`. + +### Case 5: predicates of inner tables on the outer join can't be pushed down + +```sql +create table t(id int primary key, a int not null); +create table s(id int primary key, a int not null); +explain select * from t left join s on t.a = s.a where s.a is null; ++-------------------------------+----------+-----------+---------------+-------------------------------------------------+ +| id | estRows | task | access object | operator info | ++-------------------------------+----------+-----------+---------------+-------------------------------------------------+ +| Selection_7 | 10000.00 | root | | isnull(test.s.a) | +| └─HashJoin_8 | 12500.00 | root | | left outer join, equal:[eq(test.t.a, test.s.a)] | +| ├─TableReader_13(Build) | 10000.00 | root | | data:TableFullScan_12 | +| │ └─TableFullScan_12 | 10000.00 | cop[tikv] | table:s | keep order:false, stats:pseudo | +| └─TableReader_11(Probe) | 10000.00 | root | | data:TableFullScan_10 | +| └─TableFullScan_10 | 10000.00 | cop[tikv] | table:t | keep order:false, stats:pseudo | ++-------------------------------+----------+-----------+---------------+-------------------------------------------------+ +6 rows in set (0.00 sec) +``` + +In this query，there is a predicate `s.a is null` on the inner table `s`。 + +From the `explain` results，we can see that the predicate is not pushed below join operator. This is because the outer join will fill the inner table with `NULL` values when the on condition isn't satisfied, and the predicate `s.a is null` is used to filter the results after the join. If it is pushed down to the inner table below join, the execution plan is not equivalent with the original one. + +### Case 6: the predicates which contain user variables cannot be pushed down + +```sql +create table t(id int primary key, a char); +set @a = 1; +explain select * from t where a < @a; ++-------------------------+----------+-----------+---------------+--------------------------------+ +| id | estRows | task | access object | operator info | ++-------------------------+----------+-----------+---------------+--------------------------------+ +| Selection_5 | 8000.00 | root | | lt(test.t.a, getvar("a")) | +| └─TableReader_7 | 10000.00 | root | | data:TableFullScan_6 | +| └─TableFullScan_6 | 10000.00 | cop[tikv] | table:t | keep order:false, stats:pseudo | ++-------------------------+----------+-----------+---------------+--------------------------------+ +3 rows in set (0.00 sec) +``` + +In this query，there is a predicate `a < @a` on table `t`. The `@a` of predicate is a user variable. + +As can be seen from `explain` results, the predicate is not like case 2, which is simplified to `a < 1` and pushed down to TiKV. This is because the value of the user variable `@a` may changes during the computation, and TiKV is not aware of the changes. So TiDB will not replace `@a` with `1`, and will not be pushed down to TiKV. + +An example to help understand is as follows： + +```sql +create table t(id int primary key, a int); +insert into t values(1, 1), (2,2); +set @a = 1; +select id, a, @a:=@a+1 from t where a = @a; ++----+------+----------+ +| id | a | @a:=@a+1 | ++----+------+----------+ +| 1 | 1 | 2 | +| 2 | 2 | 3 | ++----+------+----------+ +2 rows in set (0.00 sec) +``` + +As you can see from this query, the value of `@a` will change during the query. So if you replace `a = @a` with `a = 1` and push it down to TiKV, it's not an equivalent execution plan. \ No newline at end of file From 9bae922c6a694b84374367668c0c43352319caaf Mon Sep 17 00:00:00 2001 From: lzmhhh123 Date: Mon, 29 Jun 2020 17:03:09 +0800 Subject: [PATCH 02/17] fix toc --- TOC.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/TOC.md b/TOC.md index 967b11547ed7e..b4af8dcb8543a 100644 --- a/TOC.md +++ b/TOC.md @@ -99,7 +99,7 @@ + SQL Optimization + [SQL Optimization Process](/sql-optimization-concepts.md) + Logic Optimization - + [Predicates Push Down](predicates-push-down.md) + + [Predicates Push Down](/predicates-push-down.md) + [Join Reorder](/join-reorder.md) + Physical Optimization + [Statistics](/statistics.md) From ee7d02285e393cd79a996c30714a898ee9be83f9 Mon Sep 17 00:00:00 2001 From: "Zhuomin(Charming) Liu" Date: Mon, 13 Jul 2020 17:34:41 +0800 Subject: [PATCH 03/17] Update predicates-push-down.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> --- predicates-push-down.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/predicates-push-down.md b/predicates-push-down.md index fbeb952ed7761..0a29927002e6b 100644 --- a/predicates-push-down.md +++ b/predicates-push-down.md @@ -4,7 +4,7 @@ category: reference aliases: ['/docs/dev/predicates-push-down.md/','/docs/dev/reference/performance/predicates-push-down/'] --- -# Predicates Push Down(PPD) +# Predicates Push Down (PPD) This document introduces one of the TiDB's logic optimization rules—Predicate Push Down(PPD). It aims to help readers understand the predicate push down and know its suitable and unsuitable scenarios. @@ -148,4 +148,4 @@ select id, a, @a:=@a+1 from t where a = @a; 2 rows in set (0.00 sec) ``` -As you can see from this query, the value of `@a` will change during the query. So if you replace `a = @a` with `a = 1` and push it down to TiKV, it's not an equivalent execution plan. \ No newline at end of file +As you can see from this query, the value of `@a` will change during the query. So if you replace `a = @a` with `a = 1` and push it down to TiKV, it's not an equivalent execution plan. From 38070f8a341f305b91c9486a01b0d6263f6688d7 Mon Sep 17 00:00:00 2001 From: "Zhuomin(Charming) Liu" Date: Mon, 13 Jul 2020 17:35:32 +0800 Subject: [PATCH 04/17] Update predicates-push-down.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> --- predicates-push-down.md | 1 - 1 file changed, 1 deletion(-) diff --git a/predicates-push-down.md b/predicates-push-down.md index 0a29927002e6b..655da85d74622 100644 --- a/predicates-push-down.md +++ b/predicates-push-down.md @@ -1,7 +1,6 @@ --- title: Predicates Push Down category: reference -aliases: ['/docs/dev/predicates-push-down.md/','/docs/dev/reference/performance/predicates-push-down/'] --- # Predicates Push Down (PPD) From 75f635841f9f5e9018406532c3817252c4940447 Mon Sep 17 00:00:00 2001 From: "Zhuomin(Charming) Liu" Date: Mon, 13 Jul 2020 17:35:48 +0800 Subject: [PATCH 05/17] Update predicates-push-down.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> --- predicates-push-down.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/predicates-push-down.md b/predicates-push-down.md index 655da85d74622..1849ac4f74830 100644 --- a/predicates-push-down.md +++ b/predicates-push-down.md @@ -5,7 +5,7 @@ category: reference # Predicates Push Down (PPD) -This document introduces one of the TiDB's logic optimization rules—Predicate Push Down(PPD). It aims to help readers understand the predicate push down and know its suitable and unsuitable scenarios. +This document introduces one of the TiDB's logic optimization rules—Predicate Push Down (PPD). It aims to help you understand the predicate push down and know its applicable and inapplicable scenarios. PPD pushes down selection operators as close to data source as possible to complete data filtering as early as possible. Thereby significantly reducing the cost of data transmission or computation. From 135095dd702c72f079a71a376dddfbd14bcc36df Mon Sep 17 00:00:00 2001 From: "Zhuomin(Charming) Liu" Date: Mon, 13 Jul 2020 17:35:58 +0800 Subject: [PATCH 06/17] Update predicates-push-down.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> --- predicates-push-down.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/predicates-push-down.md b/predicates-push-down.md index 1849ac4f74830..ac42e0f53baaa 100644 --- a/predicates-push-down.md +++ b/predicates-push-down.md @@ -7,7 +7,7 @@ category: reference This document introduces one of the TiDB's logic optimization rules—Predicate Push Down (PPD). It aims to help you understand the predicate push down and know its applicable and inapplicable scenarios. -PPD pushes down selection operators as close to data source as possible to complete data filtering as early as possible. Thereby significantly reducing the cost of data transmission or computation. +PPD pushes down selection operators to data source as close as possible to complete data filtering as early as possible, which significantly reduces the cost of data transmission or computation. ## Examples From 81fb28799d07f17a0ff746b9736859b6202e254a Mon Sep 17 00:00:00 2001 From: "Zhuomin(Charming) Liu" Date: Mon, 13 Jul 2020 17:36:08 +0800 Subject: [PATCH 07/17] Update predicates-push-down.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> --- predicates-push-down.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/predicates-push-down.md b/predicates-push-down.md index ac42e0f53baaa..33e0d9c92b1fe 100644 --- a/predicates-push-down.md +++ b/predicates-push-down.md @@ -11,7 +11,7 @@ PPD pushes down selection operators to data source as close as possible to compl ## Examples -The following cases describes the optimization of PPD. Examples 1, 2, and 3 are cases where PPD is applicable, and examples 4, 5, and 6 are cases where PPD is not applicable. +The following cases describe the optimization of PPD. Case 1, 2, and 3 are scenarios where PPD is applicable, and Case 4, 5, and 6 are scenarios where PPD is not applicable. ### Case 1: push predicates to storage layer From 357e179a0d6a2841da2227893c49d0ec7d707d17 Mon Sep 17 00:00:00 2001 From: "Zhuomin(Charming) Liu" Date: Mon, 13 Jul 2020 17:36:24 +0800 Subject: [PATCH 08/17] Update predicates-push-down.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> --- predicates-push-down.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/predicates-push-down.md b/predicates-push-down.md index 33e0d9c92b1fe..feb88f2af232f 100644 --- a/predicates-push-down.md +++ b/predicates-push-down.md @@ -28,7 +28,7 @@ explain select * from t where a < 1; 3 rows in set (0.00 sec) ``` -In this query，pushing down the predicate `a < 1` on TiKV to filter the data can reduce the overhead caused by network transmission. +In this query, pushing down the predicate `a < 1` to the TiKV layer to filter the data can reduce the overhead of network transmission. ### Case 1: push predicates to storage layer From 5eb413023e2f056d8e54348d288ada1f507b4991 Mon Sep 17 00:00:00 2001 From: "Zhuomin(Charming) Liu" Date: Mon, 13 Jul 2020 17:36:39 +0800 Subject: [PATCH 09/17] Update predicates-push-down.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> --- predicates-push-down.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/predicates-push-down.md b/predicates-push-down.md index feb88f2af232f..490678273ee25 100644 --- a/predicates-push-down.md +++ b/predicates-push-down.md @@ -30,7 +30,7 @@ explain select * from t where a < 1; In this query, pushing down the predicate `a < 1` to the TiKV layer to filter the data can reduce the overhead of network transmission. -### Case 1: push predicates to storage layer +### Case 2: push predicates to storage layer ```sql create table t(id int primary key, a int not null); From 66f860de7d4a9023129821c79e4888d1eaf01e54 Mon Sep 17 00:00:00 2001 From: "Zhuomin(Charming) Liu" Date: Mon, 13 Jul 2020 17:37:05 +0800 Subject: [PATCH 10/17] Update predicates-push-down.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> --- predicates-push-down.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/predicates-push-down.md b/predicates-push-down.md index 490678273ee25..e727024beb56f 100644 --- a/predicates-push-down.md +++ b/predicates-push-down.md @@ -44,7 +44,7 @@ explain select * from t where a < substring('123', 1, 1); +-------------------------+----------+-----------+---------------+--------------------------------+ ``` -This query has the same execution plan as the query in case 1, because the input parameters of the `substring` of the predicate `a < substring('123', 1, 1)` are constants, so they can be calculated in advance. Then simplify to get the equivalent predicate `a < 1`. Further, TiDB can push `a < 1` down to TiKV. +This query has the same execution plan as the query in case 1, because the input parameters of the `substring` of the predicate `a < substring('123', 1, 1)` are constants, so they can be calculated in advance. Then the predicate is simplified to the equivalent predicate `a < 1`. After that, TiDB can push `a < 1` down to TiKV. ### Case 3: push predicates below join operator From 12ec3c7925b5666244596654e7c9ecca6aae5fb6 Mon Sep 17 00:00:00 2001 From: "Zhuomin(Charming) Liu" Date: Mon, 13 Jul 2020 17:37:18 +0800 Subject: [PATCH 11/17] Update predicates-push-down.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> --- predicates-push-down.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/predicates-push-down.md b/predicates-push-down.md index e727024beb56f..6c3b5b737d0b4 100644 --- a/predicates-push-down.md +++ b/predicates-push-down.md @@ -66,7 +66,7 @@ explain select * from t join s on t.a = s.a where t.a < 1; 7 rows in set (0.00 sec) ``` -In this query, the predicate `t.a < 1` is pushed below join to filter in advance, which can reduce the calculation of join. +In this query, the predicate `t.a < 1` is pushed below join to filter in advance, which can reduce the calculation overhead of join. In addition，This SQL executes an inner join, and the `ON` condition is `t.a = s.a`. The predicate `s.a <1` can be derived from `t.a < 1` and pushed down to `s` table below the join operator. Filtering the `s` table can further reduce the calculation of join. From cd2c0aa7143b8691ffd3542352fa4ff650f2b4d0 Mon Sep 17 00:00:00 2001 From: "Zhuomin(Charming) Liu" Date: Mon, 13 Jul 2020 17:37:38 +0800 Subject: [PATCH 12/17] Update predicates-push-down.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> --- predicates-push-down.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/predicates-push-down.md b/predicates-push-down.md index 6c3b5b737d0b4..2183bf757e031 100644 --- a/predicates-push-down.md +++ b/predicates-push-down.md @@ -68,7 +68,7 @@ explain select * from t join s on t.a = s.a where t.a < 1; In this query, the predicate `t.a < 1` is pushed below join to filter in advance, which can reduce the calculation overhead of join. -In addition，This SQL executes an inner join, and the `ON` condition is `t.a = s.a`. The predicate `s.a <1` can be derived from `t.a < 1` and pushed down to `s` table below the join operator. Filtering the `s` table can further reduce the calculation of join. +In addition，This SQL statement has an inner join executed, and the `ON` condition is `t.a = s.a`. The predicate `s.a <1` can be derived from `t.a < 1` and pushed down to `s` table below the join operator. Filtering the `s` table can further reduce the calculation overhead of join. ### Case 4: predicates that are not supported by storage layers cannot be pushed down From f13d5c8c63783094554768eebd402c48246cf239 Mon Sep 17 00:00:00 2001 From: "Zhuomin(Charming) Liu" Date: Mon, 13 Jul 2020 17:37:51 +0800 Subject: [PATCH 13/17] Update predicates-push-down.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> --- predicates-push-down.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/predicates-push-down.md b/predicates-push-down.md index 2183bf757e031..ca76cd09c98e0 100644 --- a/predicates-push-down.md +++ b/predicates-push-down.md @@ -109,7 +109,7 @@ explain select * from t left join s on t.a = s.a where s.a is null; In this query，there is a predicate `s.a is null` on the inner table `s`。 -From the `explain` results，we can see that the predicate is not pushed below join operator. This is because the outer join will fill the inner table with `NULL` values when the on condition isn't satisfied, and the predicate `s.a is null` is used to filter the results after the join. If it is pushed down to the inner table below join, the execution plan is not equivalent with the original one. +From the `explain` results，we can see that the predicate is not pushed below join operator. This is because the outer join fills the inner table with `NULL` values when the `on` condition isn't satisfied, and the predicate `s.a is null` is used to filter the results after the join. If it is pushed down to the inner table below join, the execution plan is not equivalent to the original one. ### Case 6: the predicates which contain user variables cannot be pushed down From b3ac938144517c594c1ce7af6d26e277da3d3e5a Mon Sep 17 00:00:00 2001 From: "Zhuomin(Charming) Liu" Date: Mon, 13 Jul 2020 17:38:03 +0800 Subject: [PATCH 14/17] Update predicates-push-down.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> --- predicates-push-down.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/predicates-push-down.md b/predicates-push-down.md index ca76cd09c98e0..e6b2e922e8e70 100644 --- a/predicates-push-down.md +++ b/predicates-push-down.md @@ -127,7 +127,7 @@ explain select * from t where a < @a; 3 rows in set (0.00 sec) ``` -In this query，there is a predicate `a < @a` on table `t`. The `@a` of predicate is a user variable. +In this query，there is a predicate `a < @a` on table `t`. The `@a` of the predicate is a user variable. As can be seen from `explain` results, the predicate is not like case 2, which is simplified to `a < 1` and pushed down to TiKV. This is because the value of the user variable `@a` may changes during the computation, and TiKV is not aware of the changes. So TiDB will not replace `@a` with `1`, and will not be pushed down to TiKV. From 282ec8a8964009228b8be8784f67daa5f1724e2d Mon Sep 17 00:00:00 2001 From: "Zhuomin(Charming) Liu" Date: Mon, 13 Jul 2020 17:38:10 +0800 Subject: [PATCH 15/17] Update predicates-push-down.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> --- predicates-push-down.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/predicates-push-down.md b/predicates-push-down.md index e6b2e922e8e70..e429e35542be4 100644 --- a/predicates-push-down.md +++ b/predicates-push-down.md @@ -129,7 +129,7 @@ explain select * from t where a < @a; In this query，there is a predicate `a < @a` on table `t`. The `@a` of the predicate is a user variable. -As can be seen from `explain` results, the predicate is not like case 2, which is simplified to `a < 1` and pushed down to TiKV. This is because the value of the user variable `@a` may changes during the computation, and TiKV is not aware of the changes. So TiDB will not replace `@a` with `1`, and will not be pushed down to TiKV. +As can be seen from `explain` results, the predicate is not like case 2, which is simplified to `a < 1` and pushed down to TiKV. This is because the value of the user variable `@a` may change during the computation, and TiKV is not aware of the changes. So TiDB does not replace `@a` with `1`, and does not push down it to TiKV. An example to help understand is as follows： From 7c884401ea413f0edad1db09bfdf6773267d1e49 Mon Sep 17 00:00:00 2001 From: "Zhuomin(Charming) Liu" Date: Mon, 13 Jul 2020 17:38:20 +0800 Subject: [PATCH 16/17] Update predicates-push-down.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> --- predicates-push-down.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/predicates-push-down.md b/predicates-push-down.md index e429e35542be4..c260cd2ffe637 100644 --- a/predicates-push-down.md +++ b/predicates-push-down.md @@ -131,7 +131,7 @@ In this query，there is a predicate `a < @a` on table `t`. The `@a` of the pred As can be seen from `explain` results, the predicate is not like case 2, which is simplified to `a < 1` and pushed down to TiKV. This is because the value of the user variable `@a` may change during the computation, and TiKV is not aware of the changes. So TiDB does not replace `@a` with `1`, and does not push down it to TiKV. -An example to help understand is as follows： +An example to help you understand is as follows： ```sql create table t(id int primary key, a int); From 3f0b5c58c0b1fc244fca4365d16b5e9a5cbe1946 Mon Sep 17 00:00:00 2001 From: Keke Yi <40977455+yikeke@users.noreply.github.com> Date: Tue, 14 Jul 2020 10:51:22 +0800 Subject: [PATCH 17/17] remove category meta --- predicates-push-down.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/predicates-push-down.md b/predicates-push-down.md index c260cd2ffe637..4aac41488e49b 100644 --- a/predicates-push-down.md +++ b/predicates-push-down.md @@ -1,6 +1,6 @@ --- title: Predicates Push Down -category: reference +summary: Introduce one of the TiDB's logic optimization rules—Predicate Push Down (PPD). --- # Predicates Push Down (PPD)