Index resolve not working for hexadecimal or bit-value literals

[kabergstrom]

I have a simple table with a 16 byte binary field called 'id', which is the primary key.

MySQL [account]> describe modifications;
+-------+------------+------+------+---------+-------+
| Field | Type       | Null | Key  | Default | Extra |
+-------+------------+------+------+---------+-------+
| id    | binary(16) | NO   | PRI  | NULL    |       |
+-------+------------+------+------+---------+-------+
1 row in set (0.16 sec)

The following equivalent queries generate different plans, with hexadecimal literals and bit-value literals doing a full table scan instead of using the primary key for the value provided.

MySQL [account]> EXPLAIN SELECT 1 FROM modifications WHERE id = UNHEX('DC454F7E0D8362B5C2E2E1E9D31B154E');
+---------------+--------------+---------------+------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----
---+
| id            | parents      | children      | task | operator info                                                                                                                                                                   | cou
nt |
+---------------+--------------+---------------+------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----
---+
| IndexScan_7   |              |               | cop  | table:modifications, index:id, range:[[220 69 79 126 13 131 98 181 194 226 225 233 211 27 21 78],[220 69 79 126 13 131 98 181 194 226 225 233 211 27 21 78]], out of order:true |
 0 |
| IndexReader_8 | Projection_3 |               | root | index:IndexScan_7                                                                                                                                                               |
 0 |
| Projection_3  |              | IndexReader_8 | root | 1                                                                                                                                                                               |
 0 |
+---------------+--------------+---------------+------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----
---+

MySQL [account]> EXPLAIN SELECT 1 FROM modifications WHERE id = x'DC454F7E0D8362B5C2E2E1E9D31B154E';
+---------------+--------------+---------------+------+----------------------------------------------------------+-------------+
| id            | parents      | children      | task | operator info                                            | count       |
+---------------+--------------+---------------+------+----------------------------------------------------------+-------------+
| TableScan_4   |              |               | cop  | table:modifications, range:(-inf,+inf), keep order:false |   366214027 |
| TableReader_5 | Selection_2  |               | root | data:TableScan_4                                         |   366214027 |
bN)                   | 292971221.6 |eReader_5 | root | eq(account.modifications.id, O~
| Projection_3  |              | Selection_2   | root | 1                                                        | 292971221.6 |
+---------------+--------------+---------------+------+----------------------------------------------------------+-------------+
4 rows in set (0.17 sec)

MySQL [account]> EXPLAIN SELECT 1 FROM modifications WHERE id = b'111000001111101100000101010110100111110000111101000001001011001010111101010010001111101111001011000011101111010001000001100100';
+---------------+--------------+---------------+------+----------------------------------------------------------+-------------+
| id            | parents      | children      | task | operator info                                            | count       |
+---------------+--------------+---------------+------+----------------------------------------------------------+-------------+
| TableScan_4   |              |               | cop  | table:modifications, range:(-inf,+inf), keep order:false |   366214027 |
| TableReader_5 | Selection_2  |               | root | data:TableScan_4                                         |   366214027 |
| Selection_2   | Projection_3 | TableReader_5 | root | eq(account.modifications.id, 8>VA,R>d)                | 292971221.6 |
| Projection_3  |              | Selection_2   | root | 1                                                        | 292971221.6 |
+---------------+--------------+---------------+------+----------------------------------------------------------+-------------+
4 rows in set (0.17 sec)

I would expect all of these queries to use the IndexReader.

I'm using TiDB version 1.0.4, Docker image release on Kubernetes.

[winoros]

Thanks for reporting, i'll looking into this.