Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
N/A
-
None
Description
We discussed the possibility of renaming the variables before. If it is to be done, it should be done before the release, after that it gets more complicated.
Currently we have 4 system variables:
7fce19bd215ac0671855044520092aa4210049d1 |
+--------------------------+-----------+ |
| Variable_name | Value |
|
+--------------------------+-----------+ |
| mhnsw_cache_size | 16777216 |
|
| mhnsw_distance_function | euclidean |
|
| mhnsw_max_edges_per_node | 6 |
|
| mhnsw_min_limit | 20 |
|
+--------------------------+-----------+ |
Considerations:
- the presence of HNSW in the name suggests there may be other algorithms in the future; if so, I think it would be more user-friendly to group all vector-related variables together, by giving them a common prefix. vector_ is first that comes to mind, for further use as vector_mhnsw_xxx, vector_lsh_xxx, etc., but maybe there are better ideas.
- I don't know whether there is already a vision how it will be configured when there are alternative algorithms, e.g. whether it would make sense to have, for example, distance_function variable for each algorithm separately, it seems too cumbersome given that the function can also be set in the table definition. If, however, any of the options will be shared among different algorithms, they should lose the algorithm prefix already now, e.g. be not [vector_]mhnsw_distance_function or some [vector_]lsh_distance_function in the future, but just vector_distance_function.
- it was also discussed that min_limit and max_edges_per_node as such are not very meaningful name and could be improved. I don't have suggestions for the better naming for them, though.
Attachments
Issue Links
- is caused by
-
MDEV-34939 vector search in 11.7
- Closed