Explain exactly what the ef_search knob on an HNSW index controls at query time.

**HNSW** (Hierarchical Navigable Small World) is the dominant ANN index type. Its three knobs are M, ef_construction, and ef_search. The first two are set at index-build time and baked into the index; ef_search is the only one set per query. **What ef_search does mechanically.** HNSW searches via greedy graph traversal at the base layer. Starting from an entry point, the search maintains a sorted list of candidate nodes ranked by distance to the query. At each step: 1. Pop the closest unvisited candidate from the list. 2. Look at its M graph neighbors. 3. Compute the distance from the query to each neighbor. 4. Add new neighbors to the candidate list. 5. Trim the list back to the top ef_search candidates. 6. Repeat until the closest unvisited candidate is farther than the K-th closest visited candidate (search has converged). ef_search is the maximum size of that candidate list. Bigger ef_search means the search considers more candidates before terminating, which raises recall (more chances to find true nearest neighbors) and per query work (more distance computations). **Typical values.** Defaults are usually 40-100. Production tuning lands between 40 and 500 depending on the recall SLO. To meet recall@10 = 0.95 on a well-tuned HNSW, ef_search around 80-200 is typical. **Per-request tuning.** Because ef_search is set at query time, you can change it without rebuilding the index. Common patterns: low ef_search for cheap autocomplete or browse queries, high ef_search for high recall RAG retrievals.

**ef_search is the maximum size of the dynamic candidate list maintained during HNSW's greedy graph descent at the base layer.** It is set at query time and is the primary lever for trading recall against per query latency in any HNSW deployment. **The search algorithm.** HNSW's search proceeds in two phases. First, traverse the upper layers (which contain progressively fewer nodes) greedily to find a near-query entry point at the base layer. Second, perform the bounded best first search at the base layer. The base-layer phase maintains two structures: a min-heap of unvisited candidates (sorted ascending by distance to query) and a set of the top-K results seen so far. ef_search bounds the candidate heap. At each step the algorithm: 1. Pops the closest unvisited candidate from the heap. 2. If it is farther than the K-th nearest result, terminate (the search has converged). 3. Otherwise, examine all M graph neighbors of the popped node. 4. For each unvisited neighbor, compute its distance to the query. Add to the heap and to the top-K results if it qualifies. 5. If the heap exceeds ef_search in size, drop the worst entries. **Why ef_search matters.** A larger ef_search keeps more 'second-best' candidates in the search frontier, which gives the algorithm more paths to explore and reduces the chance of getting stuck in a local minimum. For a randomly-built HNSW, recall@K typically follows an S-curve as ef_search increases: rapid gains from ef_search = 10 to 50, diminishing returns past 200, and asymptote near 1.0 around 500-1000. **Latency cost.** Per-query latency scales roughly linearly with ef_search because each search step does work proportional to the candidate-list size (distance computations to all newly-discovered neighbors). Doubling ef_search roughly doubles latency. **Typical values.** Defaults vary by vendor: Faiss defaults to 16, pgvector defaults to 40, Pinecone/Weaviate/Qdrant default to 100.