เพิ่มประสิทธิภาพการค้นหาแบบมีตัวกรอง

Real queries often combine a vector search with a metadata WHERE filter. Naive combinations can defeat the vector index and become slow.

ANN indexes return approximate nearest neighbors before the filter applies. If most candidates are filtered out, you may get fewer than LIMIT results — this is over-filtering.

Raise hnsw.ef_search (or IVFFlat probes) so the index scans more candidates before filtering, improving recall on selective filters.

For a common, low-cardinality filter value, build a partial index covering only those rows. The index then perfectly matches the filtered subset.

Partial indexes shine when:

• Filter values are few and known
• Each subset is large enough to matter
• Queries almost always include that filter

For high-cardinality filters, add a regular B-tree index on the metadata column. The planner can combine it with the vector scan.

Newer pgvector supports iterative scans, which keep fetching from the index until enough rows pass the filter. Enable it to avoid under-filling results.

Pre-filter: narrow rows first, then vector search (good for very selective filters). Post-filter: vector search first, then filter (good for broad filters). Test both.

Always confirm the plan. Look for Index Scan using ... hnsw rather than a sequential scan.

A robust setup often uses partial indexes for hot filters, B-tree indexes for the rest, and a tuned ef_search with iterative scans as a safety net.

Before shipping a filtered vector query:

• Verify index usage with EXPLAIN
• Confirm you reliably get LIMIT results
• Benchmark latency at p95

Test filtered search knowledge.

You learned why filters challenge ANN indexes and how partial indexes, B-tree support indexes, ef_search tuning, and iterative scans keep filtered vector queries both fast and accurate.