Comment 4 for bug 1469758

Chris,

Ben's on the right track, but it's not your index definitions, just your stats. Your bad stats are telling PG that they'll get an order of magnitude (809k vs 60k) more rows via hold_request_current_copy_before_cap_idx than is true. Increasing the stats target on action.hold_request and forcing an analyze of the table may help.

For reference, here are the lines from your paste showing the bad estimate:

-> Bitmap Heap Scan on hold_request ahr (cost=13731.63..259724.63 rows=766057 width=189) (actual time=18.921..146.235 rows=38241 loops=1)
  Recheck Cond: ((capture_time IS NULL) AND (cancel_time IS NULL))
  Filter: ((expire_time IS NULL) OR (expire_time > now()))
  Rows Removed by Filter: 24
    -> Bitmap Index Scan on hold_request_current_copy_before_cap_idx (cost=0.00..13540.12 rows=809267 width=0) (actual time=16.097..16.097 rows=59865 loops=1)