This document describes how to tune your indexes to achieve faster query performance and better recall in AlloyDB Omni.
Tune an IVF index
Tuning the values you set for the lists, ivf.probes, and the quantizer parameters might
help optimize your application's performance:
| Tuning parameter | Description | Parameter type |
|---|---|---|
lists |
The number of lists created during index building. The starting point for setting this value is (rows)/1000 for up to one million rows, and sqrt(rows) for more than one million rows. |
Index creation |
quantizer |
The type of quantizer you want to use for the K-means tree. The default value is SQ8 for better query performance. Set it to FLAT for better recall. |
Index creation |
ivf.probes |
the number of nearest lists to explore during search. The starting point for this value is sqrt(lists). |
Query runtime |
Consider the following example that shows an IVF index with the tuning parameters set:
SET LOCAL ivf.probes = 10;
CREATE INDEX my-ivf-index ON my-table
USING ivf (vector_column cosine)
WITH (lists = 100, quantizer = 'SQ8');
Handle DML invalidations due to acceleration with columnar engine
If you chose to accelerate your vector searches with the columnar engine, be aware that DML and DDL invalidations on the base tables can impact vector query performance. In case of high DML throughput, consider tuning the google_columnar_engine.refresh_threshold_percentage database flag or manually refreshing the index using the google_columnar_engine_refresh_index command.
Analyze your queries
Use the EXPLAIN ANALYZE command to analyze your query insights as shown in the following example SQL query.
EXPLAIN ANALYZE SELECT result-column
FROM my-table
ORDER BY EMBEDDING_COLUMN <-> embedding('text-embedding-005', 'What is a database?')::vector
LIMIT 1;
The example response QUERY PLAN includes information such as the time taken, the number of rows scanned or returned, and the resources used.
Limit (cost=0.42..15.27 rows=1 width=32) (actual time=0.106..0.132 rows=1 loops=1)
-> Index Scan using my-scann-index on my-table (cost=0.42..858027.93 rows=100000 width=32) (actual time=0.105..0.129 rows=1 loops=1)
Order By: (embedding_column <-> embedding('text-embedding-005', 'What is a database?')::vector(768))
Limit value: 1
Planning Time: 0.354 ms
Execution Time: 0.141 ms
View vector index metrics
You can use the vector index metrics to review performance of your vector index, identify areas for improvement, and tune your index based on the metrics, if needed.
To view all vector index metrics, run the following SQL query, which uses the
pg_stat_ann_indexes view:
SELECT * FROM pg_stat_ann_indexes;
You see output similar to the following:
-[ RECORD 1 ]----------+---------------------------------------------------------------------------
relid | 271236
indexrelid | 271242
schemaname | public
relname | t1
indexrelname | t1_ix1
indextype | scann
indexconfig | {num_leaves=100,max_num_levels=1,quantizer=SQ8}
indexsize | 832 kB
indexscan | 0
insertcount | 250
deletecount | 0
updatecount | 0
partitioncount | 100
distribution | {"average": 3.54, "maximum": 37, "minimum": 0, "outliers": [37, 12, 11, 10, 10, 9, 9, 9, 9, 9]}
distributionpercentile |{"10": { "num_vectors": 0, "num_partitions": 0 }, "25": { "num_vectors": 0, "num_partitions": 30 }, "50": { "num_vectors": 3, "num_partitions": 30 }, "75": { "num_vectors": 5, "num_partitions": 19 }, "90": { "num_vectors": 7, "num_partitions": 11 }, "95": { "num_vectors": 9, "num_partitions": 5 }, "99": { "num_vectors": 12, "num_partitions": 4 }, "100": { "num_vectors": 37, "num_partitions": 1 }}
To view number of rows created at the time of index creation, run the following command:
SELECT * FROM pg_stat_ann_index_creation;
You see output similar to the following:
-[ RECORD 1 ]----------+---------------------------------------------------------------------------
relid | 271236
indexrelid | 271242
schemaname | public
relname | t1
indexrelname | t1_ix1
index_rows_at_creation_time | 262144
For more information about the complete list of metrics, see Vector index metrics.