Add support for HAVING clause with vector searches

Summary: As titled

Differential Revision: D55833702

fbshipit-source-id: d966281

Author: saumitrp

mysql-test/suite/fb_vectordb/r/vectordb_orderby.result

@@ -50,23 +50,23 @@ id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered
 1	SIMPLE	t1	NULL	ALL	NULL	NULL	NULL	NULL	1	100.00	Using filesort
 
 
-3. Verify that the optimizer does not choose the vector index without 
+3. Verify that the optimizer DOES choose the vector index EVEN without 
 the LIMIT clause for the above 3 cases 
 
 Case A. SELECT *  
 explain select * from t1 order by FB_VECTOR_L2(vector1, '[2, 1, 1]');
 id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered	Extra
-1	SIMPLE	t1	NULL	ALL	NULL	NULL	NULL	NULL	1	100.00	Using filesort
+1	SIMPLE	t1	NULL	index	NULL	vector_key_1	65536	NULL	1	100.00	NULL
 
 Case B. SELECT <vector index field>
 explain select vector1 from t1 order by FB_VECTOR_L2(vector1, '[2, 1, 1]');
 id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered	Extra
-1	SIMPLE	t1	NULL	ALL	NULL	NULL	NULL	NULL	1	100.00	Using filesort
+1	SIMPLE	t1	NULL	index	NULL	vector_key_1	65536	NULL	1	100.00	NULL
 
 Case C. SELECT <primary key field>
 explain select id from t1 order by FB_VECTOR_L2(vector1, '[2, 1, 1]');
 id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered	Extra
-1	SIMPLE	t1	NULL	ALL	NULL	NULL	NULL	NULL	1	100.00	Using filesort
+1	SIMPLE	t1	NULL	index	NULL	vector_key_1	65536	NULL	1	100.00	NULL
 
 
 4. Verify that the optimizer chooses the vector index for an ORDER BY with 
@@ -126,25 +126,34 @@ id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered
 1	SIMPLE	t1	NULL	ALL	NULL	NULL	NULL	NULL	1	100.00	Using filesort
 
 
-6. Other scenarios - Vector dist fn as part of SELECT fields
+7. Other scenarios - Vector dist fn as part of SELECT fields
 
 Case A. SELECT *
 explain select *, FB_VECTOR_L2(vector1, '[2, 1, 1]') as dis from t1 order by dis limit 2;
 id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered	Extra
 1	SIMPLE	t1	NULL	index	NULL	vector_key_1	65536	NULL	1	100.00	NULL
+explain select *, FB_VECTOR_L2(vector1, '[2, 1, 1]') as dis from t1 having dis < 7 order by dis limit 2;
+id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered	Extra
+1	SIMPLE	t1	NULL	index	NULL	vector_key_1	65536	NULL	1	100.00	Using where
 
 Case B. SELECT <vector index field>
 explain select vector1, FB_VECTOR_L2(vector1, '[2, 1, 1]') as dis from t1 order by dis limit 2;
 id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered	Extra
 1	SIMPLE	t1	NULL	index	NULL	vector_key_1	65536	NULL	1	100.00	NULL
+explain select vector1, FB_VECTOR_L2(vector1, '[2, 1, 1]') as dis from t1 having dis < 7 order by dis limit 2;
+id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered	Extra
+1	SIMPLE	t1	NULL	index	NULL	vector_key_1	65536	NULL	1	100.00	Using where
 
 Case C. SELECT <primary key field>
 explain select id, FB_VECTOR_L2(vector1, '[2, 1, 1]') as dis from t1 order by dis limit 2;
 id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered	Extra
 1	SIMPLE	t1	NULL	index	NULL	vector_key_1	65536	NULL	1	100.00	NULL
+explain select id, FB_VECTOR_L2(vector1, '[2, 1, 1]') as dis from t1 having dis < 7 order by dis limit 2;
+id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered	Extra
+1	SIMPLE	t1	NULL	index	NULL	vector_key_1	65536	NULL	1	100.00	Using where
 
 
-7. Test ORDER BY and LIMIT pushdown to MyRocks by looking at output of Iterators 
+8. Test ORDER BY and LIMIT pushdown to MyRocks by looking at output of Iterators 
 
 Case A. SELECT *
 select * from t1 order by FB_VECTOR_L2(vector1, '[1, 2, 3]') limit 2;

mysql-test/suite/fb_vectordb/t/vectordb_orderby.test

@@ -57,7 +57,7 @@ explain select id from t1 order by FB_VECTOR_L2('[2, 1, 1]', vector1) limit 2;
 
 --echo
 --echo
---echo 3. Verify that the optimizer does not choose the vector index without 
+--echo 3. Verify that the optimizer DOES choose the vector index EVEN without 
 --echo    the LIMIT clause for the above 3 cases 
 --echo
 
@@ -137,28 +137,31 @@ explain select id from t1 order by FB_VECTOR_L2(vector1, vector1) limit 2;
 
 --echo
 --echo
---echo 6. Other scenarios - Vector dist fn as part of SELECT fields
+--echo 7. Other scenarios - Vector dist fn as part of SELECT fields
 --echo 
 
 --echo Case A. SELECT *
 
 explain select *, FB_VECTOR_L2(vector1, '[2, 1, 1]') as dis from t1 order by dis limit 2;
+explain select *, FB_VECTOR_L2(vector1, '[2, 1, 1]') as dis from t1 having dis < 7 order by dis limit 2;
 
 --echo
 --echo Case B. SELECT <vector index field>
 
 explain select vector1, FB_VECTOR_L2(vector1, '[2, 1, 1]') as dis from t1 order by dis limit 2;
+explain select vector1, FB_VECTOR_L2(vector1, '[2, 1, 1]') as dis from t1 having dis < 7 order by dis limit 2;
 
 --echo
 --echo Case C. SELECT <primary key field>
 
 explain select id, FB_VECTOR_L2(vector1, '[2, 1, 1]') as dis from t1 order by dis limit 2;
+explain select id, FB_VECTOR_L2(vector1, '[2, 1, 1]') as dis from t1 having dis < 7 order by dis limit 2;
 
 enable_warnings;
 
 --echo
 --echo
---echo 7. Test ORDER BY and LIMIT pushdown to MyRocks by looking at output of Iterators 
+--echo 8. Test ORDER BY and LIMIT pushdown to MyRocks by looking at output of Iterators 
 --echo 
 
 --echo Case A. SELECT *

sql/sql_select.cc

@@ -5071,6 +5071,7 @@ bool test_if_cheaper_ordering(const JOIN_TAB *tab, ORDER_with_src *order,
         queries too.
       */
       if (is_covering || select_limit != HA_POS_ERROR ||
+          (table->file->index_supports_vector_scan(order->order, nr)) ||
           (ref_key < 0 && (group || table->force_index_order))) {
         rec_per_key_t rec_per_key;
         KEY *keyinfo = table->key_info + nr;