A 50M-vector index supports filtering on user_id, and each user owns only about 500 vectors. With filter-aware HNSW traversal, these queries are slow and sometimes miss results because few graph neighbors match the filter. What should the query planner do?

1. A Post-filter instead and raise top-k to 10,000, since over-fetching that many candidates guarantees enough matches survive.
2. B Fetch the ~500 matching vectors via the metadata index and brute-force score them, which is exact and cheap at that size.
3. C Raise efSearch until traversal finds enough matching nodes, since a higher efSearch always restores recall under any filter.
4. D Rebuild HNSW with a larger M so the graph stays connected for every user_id value, accepting the extra memory it costs.