Exact nearest-neighbor search computes distance against every eligible row, sorts or selects the nearest candidates, and therefore has perfect recall relative to the stored candidate set. It is the quality baseline for pgvector. Begin exact, validate metrics and filters, then compare approximate indexes against those exact top-k results when scale requires lower latency.
Exact means the query finds the true nearest vectors among rows that passed its SQL predicates, under the stored values and chosen distance. It does not mean those rows are relevant to the user or factually correct. Labels evaluate relevance; exact search evaluates the approximation layer.
Without an ANN index matching the order, PostgreSQL evaluates eligible rows exactly. Relational B-tree indexes may still help narrow filters.
Combine a distance predicate with ORDER BY and LIMIT for bounded output and ANN index compatibility later. Learn thresholds from labeled score distributions; do not copy a universal “0.8 similarity” rule.
For each evaluation query, store ordered exact result IDs and distances with model, preprocessing, dataset snapshot, filter set, metric, and code revision. Run approximate search separately and compute overlap or recall@k:
This approximation recall is different from human relevance recall.
Temporarily disable index scans in an isolated evaluation transaction if you must force a baseline:
Do not change global planner settings. Inspect returned rows, execution time, buffers, and eligible row count.
Generate a benchmark plan for exact pgvector search using my row count, dimensions, metric, filters, and top-k [values]. Include fixture snapshotting, warm/cold runs, query-plan capture, human relevance labels, and how exact results will become the ANN comparison baseline.
Verification contract: The plan must keep approximation recall, task relevance, database latency, and end-to-end latency as separate measures.