Applies to VAST Cluster 5.5.
You can tune how much of the vector index a search reads with ADBC session settings. They apply to the searches on one ADBC connection. This page is the reference for the settings VAST Cluster 5.5 reads: their names, formats, defaults and how to set them.
Most applications don't need them: the cluster's defaults are a good starting point. Change them only to trade speed for recall (or the other way round), and measure the effect; see performance.
How to set them
Set them as ADBC connection options named vast.db.setting.<name>, after you connect and before you run the search:
import os
import adbc_driver_manager.dbapi as dbapi
import adbc_driver_vastdb
conn = dbapi.connect(
driver=adbc_driver_vastdb.get_driver_path(),
db_kwargs={
"vast.db.endpoint": os.environ["QE_ENDPOINT"],
"vast.db.access_key": os.environ["AWS_ACCESS_KEY_ID"],
"vast.db.secret_key": os.environ["AWS_SECRET_ACCESS_KEY"],
},
autocommit=True,
)
conn.adbc_connection.set_options(**{
"vast.db.setting.vector_search_min_prob": "<a>,<b>,<c>,<d>",
"vast.db.setting.vector_search_max_prob": "<a>,<b>,<c>,<d>",
})
- They aren't accepted as database options in
db_kwargs. Set them on the connection. - You can't set them with SQL.
SET VARIABLEfails withThe operator 'SET_VARIABLE' type=70 is currently not supported. - The Python SDK's
vector_search()has no way to pass them, so it always uses the cluster's defaults. To tune a search from Python, run the SQL yourself on an ADBC connection; see ADBC.
Query design shows a captured example that sets them.
Settings
Name (after vast.db.setting.) |
Format | What it controls | Default |
|---|---|---|---|
vector_search_min_prob |
Four integers, comma-separated, one per index level | The minimum number of clusters the search reads at each level. | 150,30,4,4 |
vector_search_max_prob |
Four integers, comma-separated, one per index level | The maximum number of clusters the search reads at each level. | 3000,200,8,8 |
vector_search_pruning_distance_ratio |
Four numbers, comma-separated, one per index level | Between the minimum and the maximum, the search reads the next-closest cluster only while it's close enough: its distance must be at most the closest cluster's distance plus (ratio − 1) times the absolute value of that distance. A higher ratio reads more clusters. | 1.9,1.9,1.9,1.9 |
vector_search_skip_recent_non_indexed |
"1" or "0" ("true" and "false" fail) |
"1" skips recently inserted rows that aren't in the index yet. Faster after a large load, but those rows can't be returned. |
"0": recent rows are searched |
vector_search_defer_projection |
"1" or "0" |
"1" reads the other columns only for the rows the search returns, instead of for every candidate. It applies only to a simple query: one projection over the table scan. |
"1" |
The search always reads the parts of the index that are still being built. These settings control how many of the other clusters it reads. Reading more clusters (higher min_prob or max_prob, or a higher ratio) usually raises recall and latency. Setting the minimum and the maximum to the same values makes the search read exactly that many clusters at each level, which gives a repeatable trial.
The first value in each list is for the lowest level of the index, the clusters that hold the rows. It has the most effect on recall: pinning the first value to 1 cuts recall noticeably, while pinning the last value to 1 has little effect. Likewise, vector_search_skip_recent_non_indexed set to "1" lowers recall on a table with rows not yet in the index.
The defaults are cluster settings: 150,30,4,4 for the minimum, 3000,200,8,8 for the maximum and 1.9 at every level for the ratio, unless your platform team has changed them. There's no SQL to read them, so record the values you start from before you change anything.
Values aren't validated
The cluster doesn't return an error for a misspelt setting name or a malformed value, and a list with the wrong number of values is accepted too. The search then runs with the defaults. Check what you set: a typo looks like a setting with no effect.
Choosing values
Which setting to change depends on what you're trying to improve. The table gives the direction to move each one, not values: start from your cluster's defaults, change one setting at a time, and measure recall and latency after each change (measure recall and latency).
| Goal | Setting | Direction |
|---|---|---|
| Higher recall, for example for RAG, where a missed chunk means a worse answer | The first value of vector_search_min_prob |
Raise it |
| Lower latency, or more queries per second | vector_search_max_prob and vector_search_pruning_distance_ratio |
Lower max_prob, or keep the defaults |
| Selective filters, such as one tenant or a rare tag | The first value of vector_search_max_prob |
Raise it, so the search can read enough clusters to fill the LIMIT. Test this with your own filters. |
| Just after a large load | vector_search_skip_recent_non_indexed |
Set it to "1" only if it's acceptable for recent rows to be missing from results |
| Exploring or debugging | vector_search_min_prob and vector_search_max_prob |
Set them to the same values, for repeatable measurements |
For recommended values by workload, see best practices.