`my_table` includes:

```
user_id                | character varying           |           | not null |
epic_id                | text                        |           | not null |

"IDX_user" UNIQUE, btree ("user_id") WHERE status < 101
"IDX_epic" UNIQUE, btree ("epic_id") WHERE status < 101 

```

Problematic Query
-----------------

```
EXPLAIN ANALYZE SELECT * FROM my_table WHERE "epic_id" = 'asdf' and "status" < 101 LIMIT 1;

 Limit  (cost=0.28..8.29 rows=1 width=276) (actual time=0.230..0.231 rows=0 loops=1)
   ->  Index Scan using "IDX_user" on my_table  (cost=0.28..8.29 rows=1 width=276) (actual time=0.229..0.230 rows=0 loops=1)
         Filter: ("epic_id" = 'asdf'::text)
         Rows Removed by Filter: 273
 Planning Time: 0.122 ms
 Execution Time: 0.248 ms

```

There's a perfectly good `IDX_epic`. Why are we using `IDX_user`, traversing 100s of rows, and potentially causing annoying locks when this is used within a transaction?

Fun Tidbits
-----------

* `SET random_page_cost=1` does not help as other stackoverflow posts have recommended
* On local, it uses the correct index! There are only 90 rows on local with `status < 101`
* When doing an inner join of `"epic_id" = table.random_column`, the plan *does* use `IDX_epic`.
* `"user_id"` and `"epic_id"` are different types, but from what I've read the difference between `text` and `character varying` is near 0.
* According to `pg_stat_all_indexes`, `IDX_epic` has an `idx_scan` of 9, which confirms it's not being used except for my tests.