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
Currently, vector indexes are only applied to a very specific type of query:
SELECT ... FROM ... ORDER BY VEC_DISTANCE(literal, field) LIMIT lim;
But we should be more flexible in what we support.
For instance, we probably don't need to require that one side of the distance function is a literal, as long as it comes from a source that only has one row.
Alternatively, if neither input to VEC_DISTANCE is a literal but one input is estimated to have a small number of rows, we could run a subquery for each row and then merge the results.
I'm sure there's other types of queries we may want to support, but we should see how vector indexes are actually being used and handle cases based on user need.
The text was updated successfully, but these errors were encountered:
Currently, vector indexes are only applied to a very specific type of query:
SELECT ... FROM ... ORDER BY VEC_DISTANCE(literal, field) LIMIT lim;
But we should be more flexible in what we support.
For instance, we probably don't need to require that one side of the distance function is a literal, as long as it comes from a source that only has one row.
Alternatively, if neither input to
VEC_DISTANCE
is a literal but one input is estimated to have a small number of rows, we could run a subquery for each row and then merge the results.I'm sure there's other types of queries we may want to support, but we should see how vector indexes are actually being used and handle cases based on user need.
The text was updated successfully, but these errors were encountered: