Skip to content
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

empty result when query contains "in (v1, v2 .. )" #22894

Closed
ChenPeng2013 opened this issue Feb 23, 2021 · 4 comments · Fixed by #22938
Closed

empty result when query contains "in (v1, v2 .. )" #22894

ChenPeng2013 opened this issue Feb 23, 2021 · 4 comments · Fixed by #22938
Assignees
Labels
severity/major sig/planner SIG: Planner type/bug The issue is confirmed as a bug.

Comments

@ChenPeng2013
Copy link
Contributor

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

use test;
drop table if exists IDT_RP2205;
CREATE TABLE `IDT_RP2205` (   `COL1` tinyint(11) DEFAULT '24' COMMENT 'NUMERIC UNIQUE INDEX') ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin PARTITION BY RANGE ( `COL1`%44 ) (   PARTITION `P0` VALUES LESS THAN (0),   PARTITION `P1` VALUES LESS THAN (10),   PARTITION `P2` VALUES LESS THAN (20),   PARTITION `P3` VALUES LESS THAN (30),   PARTITION `P4` VALUES LESS THAN (40),   PARTITION `P5` VALUES LESS THAN (50),   PARTITION `PMX` VALUES LESS THAN (MAXVALUE) );
insert into IDT_RP2205 values(127);
select * from IDT_RP2205 where col1 in (127);
select * from IDT_RP2205 where col1 in (127,127);

2. What did you expect to see? (Required)

mysql> select * from IDT_RP2205 where col1 in (127);
+------+
| COL1 |
+------+
|  127 |
+------+
1 row in set (0.01 sec)

mysql> select * from IDT_RP2205 where col1 in (127,127);
+------+
| COL1 |
+------+
|  127 |
+------+

3. What did you see instead (Required)

mysql> select * from IDT_RP2205 where col1 in (127);
+------+
| COL1 |
+------+
|  127 |
+------+
1 row in set (0.01 sec)

mysql> select * from IDT_RP2205 where col1 in (127,127);
Empty set (0.00 sec)

4. What is your TiDB version? (Required)

master 3edbab3 and release-5.0-rc 760c7d1

@ChenPeng2013 ChenPeng2013 added the type/bug The issue is confirmed as a bug. label Feb 23, 2021
@guo-shaoge
Copy link
Collaborator

/assign @guo-shaoge

@crazycs520
Copy link
Contributor

related issue: #22898 @tiancaiamao PTAL

@guo-shaoge
Copy link
Collaborator

guo-shaoge commented Feb 25, 2021

We got bug in partition prune for in expr. We directly use 127 to get partition, but actually we should use 127%xxx.

mysql> explain select * from IDT_RP2205 where col1 in (127,127);
+-------------------------+----------+-----------+---------------------------------+------------------------------------+
| id                      | estRows  | task      | access object                   | operator info                      |
+-------------------------+----------+-----------+---------------------------------+------------------------------------+
| TableReader_9           | 10.00    | root      |                                 | data:Selection_8                   |
| └─Selection_8           | 10.00    | cop[tikv] |                                 | in(test.idt_rp2205.col1, 127, 127) |
|   └─TableFullScan_7     | 10000.00 | cop[tikv] | table:IDT_RP2205, partition:pmx | keep order:false, stats:pseudo     |
+-------------------------+----------+-----------+---------------------------------+------------------------------------+
3 rows in set (0.00 sec)

mysql> explain select * from IDT_RP2205 where col1 in (127);
+-------------------------+---------+-----------+--------------------------------+--------------------------------+
| id                      | estRows | task      | access object                  | operator info                  |
+-------------------------+---------+-----------+--------------------------------+--------------------------------+
| TableReader_9           | 0.00    | root      |                                | data:Selection_8               |
| └─Selection_8           | 0.00    | cop[tikv] |                                | eq(test.idt_rp2205.col1, 127)  |
|   └─TableFullScan_7     | 1.00    | cop[tikv] | table:IDT_RP2205, partition:p1 | keep order:false, stats:pseudo |
+-------------------------+---------+-----------+--------------------------------+--------------------------------+
3 rows in set (0.00 sec)

PS: why the second plan is correct: in expr is rewrite as equal expr.

guo-shaoge added a commit to guo-shaoge/tidb that referenced this issue Feb 25, 2021
guo-shaoge added a commit to guo-shaoge/tidb that referenced this issue Feb 25, 2021
@XuHuaiyu XuHuaiyu added sig/planner SIG: Planner and removed sig/execution SIG execution labels Feb 26, 2021
@ti-srebot
Copy link
Contributor

ti-srebot commented Mar 3, 2021

Please edit this comment or add a new comment to complete the following information

Not a bug

  1. Remove the 'type/bug' label
  2. Add notes to indicate why it is not a bug

Duplicate bug

  1. Add the 'type/duplicate' label
  2. Add the link to the original bug

Bug

Note: Make Sure that 'component', and 'severity' labels are added
Example for how to fill out the template: #20100

1. Root Cause Analysis (RCA) (optional)

2. Symptom (optional)

3. All Trigger Conditions (optional)

4. Workaround (optional)

5. Affected versions

[v4.0.0:v4.0.11],[v5.0.0-rc]

6. Fixed versions

master

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severity/major sig/planner SIG: Planner type/bug The issue is confirmed as a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants