You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
droptable if exists t;
createtablet(a bigint, b bigint, index idx(a, b));
Now let's issue a query on column 'a':
TiDB(localhost:4000) > explain select * from t where a in (1, 2) and a in (1, 3);
+---------------------+-------+------+-------------------------------------------------------------------------+
| id | count | task | operator info |
+---------------------+-------+------+-------------------------------------------------------------------------+
| IndexReader_10 | 0.04 | root | index:Selection_9 |
| └─Selection_9 | 0.04 | cop | in(test.t.a, 1, 2) |
| └─IndexScan_8 | 20.00 | cop | table:t, index:a, b, range:[1,1], [3,3], keep order:false, stats:pseudo |
+---------------------+-------+------+-------------------------------------------------------------------------+
3 rows in set (0.00 sec)
As you can see, this results in a IndexScan_8 followed by a Selection_9, and the query range in IndexScan_8 is [1,1], [3,3].
If we could handle more than one 'equal' or 'in' function for a column in the ranger, we can optimize the query to only one IndexScan with the query range [1, 1].
In "util/ranger/detacher.go", we have to enhance the extractEqAndInCondition function to break this limit.
The text was updated successfully, but these errors were encountered:
Take this as an example:
Now let's issue a query on column 'a':
As you can see, this results in a
IndexScan_8
followed by aSelection_9
, and the query range inIndexScan_8
is[1,1], [3,3]
.If we could handle more than one 'equal' or 'in' function for a column in the ranger, we can optimize the query to only one
IndexScan
with the query range[1, 1]
.In "util/ranger/detacher.go", we have to enhance the
extractEqAndInCondition
function to break this limit.The text was updated successfully, but these errors were encountered: