Снова подниму вопрос: как заставить pg использовать НУЖНЫЙ индекс?

Имеется таблица orders


=> EXPLAIN ANALYZE SELECT
    *
FROM
    "orders" "o"
WHERE

        "o"."status" IN ('confirm', 'accept', 'driving', 'waiting', 'transporting')


        AND "o"."gid" = 1
        AND "o"."sid" = 147
;


 Bitmap Heap Scan on orders o  (cost=34577.20..44323.96 rows=2449 width=1867) (actual time=219.683..219.683 rows=0
loops=1)
   Recheck Cond: ((gid = 1) AND (sid = 147) AND (status = ANY
('{confirm,accept,driving,waiting,transporting}'::text[])))
   ->  BitmapAnd  (cost=34577.20..34577.20 rows=2449 width=0) (actual time=218.928..218.928 rows=0 loops=1)
         ->  Bitmap Index Scan on dispatcher_history_sign_idx  (cost=0.00..6605.57 rows=99301 width=0) (actual
time=104.751..104.751rows=180593 loops=1) 
               Index Cond: ((gid = 1) AND (sid = 147))
         ->  Bitmap Index Scan on driver_work_index  (cost=0.00..27970.15 rows=1111648 width=0) (actual
time=60.356..60.356rows=34898 loops=1) 
               Index Cond: (status = ANY ('{confirm,accept,driving,waiting,transporting}'::text[]))
 Total runtime: 219.814 ms
(8 строк)


Видно что Pg зачем-то использует ДВА индекса и делает их BitmapAnd
при этом выбирает 34 тысячи плюс 180 тысяч записей чтобы итого
получить ноль.
Если бы он использовал нужный индекс он бы мог получить этот ответ сразу.

хотя построен такой индекс:

"edispatcher_orders_service_idx" (gid, sid)
     WHERE status = ANY (ARRAY['confirm'::text, 'accept'::text, 'driving'::text, 'waiting'::text,
'transporting'::text])

Этот индекс построен специально под этот запрос, однако он использует такие
индексы:

"driver_work_index" btree (did, status)
     WHERE status = ANY (ARRAY['confirm'::text, 'accept'::text, 'driving'::text, 'waiting'::text,
'transporting'::text])

"dispatcher_history_sign_idx" btree (gid, sid, did, booking_time)

это индексы для разных списков разным интерфейсам. Удаляю любой из вторых
индексов - Pg начинает использовать нужный мне индекс и все начинает
летать. Но те другие индексы нужны для других запросов и
соответственно они начинают лагать.

Pg 9.3.1
--

. ''`.                               Dmitry E. Oboukhov
: :’  :   email: unera@debian.org jabber://UNera@uvw.ru
`. `~’              GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537