Explain HNSW: how it works at a high level, its main tuning parameters, and its operational costs.

Hierarchical Navigable Small World builds a layered proximity graph — each node appears in the bottom layer and, with exponentially decreasing probability, in higher layers. Search enters at the top, greedily walks toward the query, and drops down a layer each time it reaches a local minimum, finally doing a beam search (width ef_search) at layer 0. Parameters: M controls graph connectivity (higher = better recall, more memory — typically 16-64); ef_construction controls build-time effort (higher = better graph, slower build); ef_search is the runtime knob you actually operate — raise it for recall, lower it for latency, per-query if needed. Operational realities: memory — the graph plus vectors must effectively be RAM-resident for advertised latencies (a common sizing surprise; quantization/PQ variants exist to compress); build cost — indexing millions of vectors is hours of CPU, and in pgvector an HNSW build/rebuild has historically contended with writes, so plan maintenance windows or blue/green indexes; churn — deletes are usually tombstones and heavy update traffic degrades graph quality until compaction/rebuild. Contrast with IVF (cluster-then-probe: cheaper memory, faster builds, generally lower recall at same latency) and disk-based indexes (DiskANN-style) for corpora too big for RAM.