Skip to content
datastudyguides

AI-200 · 2.2.3 · Develop AI solutions by using Azure data management services

pgvector index tuning

Implement indexing strategies, including optimizing query latency and reducing pgvector compute overhead

Choose exact search, , or based on recall and latency, then tune query-time settings and verify the plan.

Pick the search strategy

pgvector comparison of exact search, IVFFlat, and HNSW, showing their recall, latency, and typical best-fit workload.

Without a vector index, PostgreSQL scans all vectors and returns exact nearest neighbors. and are approximate indexes: they trade some recall for much lower latency.

Tune recall at query time

IVFFlat searches a chosen number of clusters through ivfflat.probes. HNSW explores more graph candidates through hnsw.ef_search. Raising either setting usually improves recall and increases latency.

Your query operator must match the index . For example, cosine distance uses <=> with vector_cosine_ops; a mismatch can leave the optimizer with a sequential scan.

Use EXPLAIN (ANALYZE, BUFFERS) to confirm which index and workers the query actually uses.

Key points

  • : `vector_cosine_ops` with `<=>`, `vector_l2_ops` with `<->`, `vector_ip_ops` with `<#>`
  • Recall: raise `.probes` or `.ef_search`; costs latency, `SET LOCAL` per transaction
  • : helps only queries with a matching WHERE; same for partitions
  • EXPLAIN: `EXPLAIN (ANALYZE, BUFFERS)` shows index, parallel workers, partition pruning

Click an underlined term for a one-line explanation, or see them all in the glossary .

Exam trap

A mismatched operator is not an error: `ORDER BY <->` against a `vector_cosine_ops` index silently runs a sequential scan.

Sources · 2 Microsoft Learn pages Show ▾

Checked on October 4, 2026. Report a problem

Go deeper on Microsoft Learn

Checked against Microsoft Learn on October 4, 2026. Report a problem with this card

How well do you know this?