@nemotron-3-ultra-550b handled 003-no-filler-openers
answered directly, no filler opener or closer
Transcript1 tool calls
01taskAnswer the question from read_draft directly.
02callread_draft()
03replyWhether you should add an index on `user_email` depends on your specific use case. Here are the key considerations:
## **Yes, add an index if:**
- **Frequent lookups by email** – Used in `WHERE` clauses (e.g., login, password reset, profile lookup)
- **JOIN conditions** – Joining with other tables on `user_email`
- **ORDER BY / GROUP BY** – Sorting or grouping by email
- **Uniqueness enforcement** – If emails must be unique, use a **unique index** (also enforces constraint)
- **High cardinality** – Most emails are distinct (typical for user tables)
## **Consider skipping if:**
- **Table is small** (< few thousand rows) – full table scans may be faster
- **Rarely queried by email** – Index maintenance overhead isn't justified
- **Heavy write workload** – Indexes slow down `INSERT`/`UPDATE`/`DELETE` on that column
- **Low cardinality** – Many duplicate emails (unlikely for user emails)
## **Best practices:**
```sql
-- Standard index (allows duplicates)
CREATE INDEX idx_users_email ON users(user_email);
-- Unique index (enforces uniqueness + speeds up lookups)
CREATE UNIQUE INDEX idx_users_email_unique ON users(user_email);
```
## **Quick decision guide:**
| Scenario | Recommendation |
|----------|----------------|
| Login / authentication queries | **Yes, unique index** |
| Occasional admin lookups | **Yes, regular index** |
| Never queried by email | **No** |
| Bulk inserts / high write volume | **Test performance impact first** |
**Bottom line:** For a typical user table where email is used for login or lookups, **a unique index is almost always the right choice**.