Support Batch Lookup With VIndex Functions in Planner

[mattlord]

Feature Description

Vitess provides a nice method to know where a row would land in the keyspace by allowing you to query the vindex function and pass it an id value to see which shard the row would land on:

mysql> select * from customer.hash where id = 5;
+------+-------------+-------------+-----------+------------------+-------+
| id   | keyspace_id | range_start | range_end | hex_keyspace_id  | shard |
+------+-------------+-------------+-----------+------------------+-------+
| 5    | p�<�
             �z    |             | �         | 70bb023c810ca87a | -80   |
+------+-------------+-------------+-----------+------------------+-------+
1 row in set (0.00 sec)

However, you must perform this check one id at a time. This makes it less convenient when you are planing to do large bulk inserts / data loads:

mysql> select id, hex_keyspace_id, shard from customer.hash where id IN (5,9999);
ERROR 1105 (HY000): unsupported: where clause for vindex function must be of the form id = <val> (not equality)

mysql> select id, hex_keyspace_id, shard from customer.hash where id = 5;
+------+------------------+-------+
| id   | hex_keyspace_id  | shard |
+------+------------------+-------+
| 5    | 70bb023c810ca87a | -80   |
+------+------------------+-------+
1 row in set (0.00 sec)

mysql> select id, hex_keyspace_id, shard from customer.hash where id = 9999;
+------+------------------+-------+
| id   | hex_keyspace_id  | shard |
+------+------------------+-------+
| 9999 | 9a49bef394017d2d | 80-   |
+------+------------------+-------+
1 row in set (0.00 sec)

Use Case(s)

It's common to have bulk data copy/load pipelines (ETL or other asynchronous data pipelines). In this pipeline you will often perform transformations to support loading this data in the most efficient way knowing the details of the target database. With Vitess, it would be nice to check the landing keyspace_id/shard for rows in bulk in order to more efficiently organize data in the pipeline so that it's grouped by shard in order to load the data as quickly as possible in Vitess with limited impact/load on the database (e.g. generating multi-row INSERTs for each shard).