Recipe: starting parameters from the documentation
The rules are the ones in pgvector's documentation (checked on 2026-10-11); they are starting points for any IVF or HNSW index, not guarantees.
Recipes to copy into any vector search project: test whether you need an index at all, start from documented parameters, benchmark against exact search, shrink and re-score, choose a filter strategy, and keep recall from silently dropping.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write check_recall_floor(recall, floor) that returns "ok: recall 0.970 meets the floor 0.950" when recall is at least the floor and "FAIL: recall 0.930 is below the floor 0.950" otherwise (3 decimals). Print the result for 0.93 and 0.97 with a floor of 0.95.
Write needs_index(n, dim, budget_ms) that estimates the exact query time as n * dim // 1000000 milliseconds and returns "yes" when twice that is above the budget, otherwise "no". Print the answer for 50,000, 200,000 and 1,000,000 vectors of 384 numbers with a 200 ms budget.
Explain it without notes
Walk through the test for whether a project needs a vector index.
Where would you start with IVF and HNSW parameters, and what do you do next?
What does the benchmark harness need, and why must it work with any search function?
What belongs in CI to protect recall, and what does it not protect against?
Expected output
IVF for 10000 rows: start with lists=10, probes=3
IVF for 100000 rows: start with lists=100, probes=10
IVF for 1000000 rows: start with lists=1000, probes=31
IVF for 10000000 rows: start with lists=3162, probes=56
HNSW: start with m=16, ef_construction=64, ef_search=40
Then measure recall (Topic 3.6) and move one knob at a time.