-
Notifications
You must be signed in to change notification settings - Fork 5.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dml: select result is not compatible with MySQL while joining a subquery with a where clause evaluated to false #24865
Labels
Comments
PragmaTwice
changed the title
dml: select result is not compatible with MySQL while joining a subquery with a where clause evaluated to false
dml: select result is not compatible with MySQL while joining a subquery with a where clause with truncated values
May 25, 2021
PragmaTwice
changed the title
dml: select result is not compatible with MySQL while joining a subquery with a where clause with truncated values
dml: select result is not compatible with MySQL while joining a subquery with a where clause evaluated to false
May 25, 2021
A simplified case: tidb> desc analyze SELECT count(*) FROM t2 _tmp_3 JOIN ( SELECT COUNT(_tmp_6.i2) AS _tmp_7 FROM t1 _tmp_5 JOIN t2 _tmp_6 WHERE _tmp_5.c1 != 1 AND _tmp_6.c2 > 100 ) _tmp_4 ;
+----------------------------------------+---------+---------+-----------+---------------+------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------+-----------+---------+
| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
+----------------------------------------+---------+---------+-----------+---------------+------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------+-----------+---------+
| StreamAgg_15 | 1.00 | 1 | root | | time:287.3µs, loops:2 | funcs:count(1)->Column#13 | 8 Bytes | N/A |
| └─HashJoin_33 | 6.00 | 0 | root | | time:284.8µs, loops:1, build_hash_table:{total:204.3µs, fetch:204.3µs, build:0s} | CARTESIAN inner join | 0 Bytes | 0 Bytes |
| ├─Projection_20(Build) | 1.00 | 0 | root | | time:105.3µs, loops:1, Concurrency:OFF | 1->Column#19 | 372 Bytes | N/A |
| │ └─StreamAgg_22 | 1.00 | 0 | root | | time:103.7µs, loops:1 | funcs:firstrow(1)->Column#18 | 16 Bytes | N/A |
| │ └─HashJoin_32 | 15.36 | 0 | root | | time:102.5µs, loops:1, build_hash_table:{total:111.9µs, fetch:111.9µs, build:0s} | CARTESIAN inner join | 0 Bytes | 0 Bytes |
| │ ├─TableReader_27(Build) | 3.20 | 3 | root | | time:26.6µs, loops:1, cop_task: {num: 1, max: 228.5µs, proc_keys: 0, rpc_num: 1, rpc_time: 213.3µs, copr_cache_hit_ratio: 0.00} | data:Selection_26 | 297 Bytes | N/A |
| │ │ └─Selection_26 | 3.20 | 3 | cop[tikv] | | tikv_task:{time:51.2µs, loops:4} | ne(cast(test.t1.c1, double BINARY), 1) | N/A | N/A |
| │ │ └─TableFullScan_25 | 4.00 | 4 | cop[tikv] | table:_tmp_5 | tikv_task:{time:5.17µs, loops:4} | keep order:false, stats:pseudo | N/A | N/A |
| │ └─TableReader_30(Probe) | 4.80 | 0 | root | | time:59.1µs, loops:1, cop_task: {num: 1, max: 178.6µs, proc_keys: 0, rpc_num: 1, rpc_time: 171.5µs, copr_cache_hit_ratio: 0.00} | data:Selection_29 | 327 Bytes | N/A |
| │ └─Selection_29 | 4.80 | 0 | cop[tikv] | | tikv_task:{time:78.9µs, loops:6} | gt(cast(test.t2.c2, double BINARY), 100) | N/A | N/A |
| │ └─TableFullScan_28 | 6.00 | 6 | cop[tikv] | table:_tmp_6 | tikv_task:{time:4.04µs, loops:6} | keep order:false, stats:pseudo | N/A | N/A |
| └─TableReader_19(Probe) | 6.00 | 6 | root | | time:138.7µs, loops:1, cop_task: {num: 1, max: 150µs, proc_keys: 0, rpc_num: 1, rpc_time: 127.2µs, copr_cache_hit_ratio: 0.00} | data:TableFullScan_18 | 160 Bytes | N/A |
| └─TableFullScan_18 | 6.00 | 6 | cop[tikv] | table:_tmp_3 | tikv_task:{time:4.57µs, loops:6} | keep order:false, stats:pseudo | N/A | N/A |
+----------------------------------------+---------+---------+-----------+---------------+------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------+-----------+---------+
13 rows in set, 7 warnings (0.00 sec) As we can see from |
XuHuaiyu
added
sig/planner
SIG: Planner
and removed
sig/sql-infra
SIG: SQL Infra
labels
May 27, 2021
Minimal reproduction:
|
Closed
Please edit this comment or add a new comment to complete the following informationNot a bug
Duplicate bug
BugNote: Make Sure that 'component', and 'severity' labels are added 1. Root Cause Analysis (RCA) (optional)2. Symptom (optional)3. All Trigger Conditions (optional)4. Workaround (optional)5. Affected versions6. Fixed versions |
A complementary fix for the original case in the description: #25289 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Bug Report
Please answer these questions before submitting your issue. Thanks!
1. Minimal reproduce step (Required)
2. What did you expect to see? (Required)
in MySQL:
3. What did you see instead (Required)
in TiDB:
The result is zero even type of
t1.c1
andt2.c2
(char) is replaced with integer, so it is not due to truncated values (message in warnings)4. What is your TiDB version? (Required)
The text was updated successfully, but these errors were encountered: