[Bug] In the latest version of IoTDB, When multiple elements exist under a certain node, there is an error in filtering data using the TIME field.
- Dominant language
- Java
- Stars
- 6.4k
- Forks
- 1.2k
- Avg merge
- 1d 23h
- Merged PRs (30d)
- 115
Description
### Search before asking
- [X] I searched in the [issues](https://github.com/apache/iotdb/issues) and found nothing similar.
### Version
version 1.3.3 (Build: ad95a7e)
### Describe the bug and provide the minimal reproduce step
```
# statement 1
DROP DATABASE root.db0
CREATE TIMESERIES root.db0.t1.c0 WITH datatype=INT32
INSERT INTO root.db0.t1(timestamp, c0) VALUES (1641024000000, 1);
SELECT * FROM root.db0.t1 WHERE time < 1641024150000 - 1000;
# statement 2
DROP DATABASE root.db1
CREATE TIMESERIES root.db1.t1.c0 INT32;
CREATE TIMESERIES root.db1.t1.c1 INT32;
CREATE TIMESERIES root.db1.t1.c2 WITH datatype=INT32;
INSERT INTO root.db1.t1(timestamp, c2, c1, c0) VALUES (1641024000000, 1, 1, 1);
SELECT * FROM root.db1.t1 WHERE time < 1641024150000 - 1000;
```
### What did you expect to see?
Expected result set for statement 1: **1**
Expected result set for statement 1: **1**
### What did you see instead?
statement 1 returned result set: **1**
statement 2 returned result set: [INTERNAL_SERVER_ERROR(305)] Exception occurred: "SELECT * FROM root.db1.t1 WHERE (time) < 1641024150000 - 1000". executeStatement failed. null
### Anything else?
Dear IoTDB team, Statement 1 and Statement 2 perform the same query, with the only difference being that the data nodes are different. The data node in Statement 2 contains multiple elements. Theoretically, the query results of both should be identical, but an error occurs when executing Statement 2.
### Are you willing to submit a PR?
- [ ] I'm willing to submit a PR!
Contributor guide
Research direction
Start by running the two SQL reproductions from the issue against IoTDB version 1.3.3, comparing the single-element and multiple-element cases. Trace the TIME-filter query path for statement 2 and confirm the fix makes both queries return the expected result set without INTERNAL_SERVER_ERROR.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100