Re: Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] Снова подниму вопрос: как заставить pg использовать НУЖНЫЙ индекс?

> Я бы ещё крепко задумался о снижении количества индексов. Например, сам по себе
> "driver_work_index" btree (did, status)
> WHERE status = ANY (ARRAY['confirm'::text, 'accept'::text,
> 'driving'::text, 'waiting'::text, 'transporting'::text])

Имеется водитель. он видит свои заказы
у него
    WHERE
            did = ?
        AND status IN (..)
    ORDER BY
        status;

соответственно для его запроса построен индекс.
допустим ORDER BY можно убрать или оставить но убрать в индексе.
Но число индексов от этого не поменяется.

Далее имеется наблюдатель (диспетчер) у него

WHERE
        gid = ?
    AND sid = ?
    AND status IN (...)

и имеется другой наблюдатель

WHERE
        gid = ?
    AND status IN (...)

соответственно для водителя один индекс, для обоих наблюдателей
другой.

оба индекса частичные, занимают очень немного (то есть содержат в себе
максимум 500-1000 записей в работе)


> — странный. Зачем пихать status вторым слоем,

ORDER BY еще там есть в запросах. Впрочем можно убрать. вопрос в другом.
почему имея точный pattern индекса и WHERE условия Pg принимает
решение работать по двум индексам вместо одного точно подходящего и из
за этого получаем в 2000 раз меньшую производительность.


> Индекс по (gid, sid, did, booking_time) — выглядит монстрообразно. Опять же,
> есть серьёзное подозрение, что 3й и 4й слои не так уж и нужны.

Это для отчетов.
Там WHERE такой:

WHERE
        gid = ?
    AND sid = ?
    AND did = ?
    AND booking_time BETWEEN ? AND ?

> В общем, главных слова, как обычно два — кардинальность и селективность.

я смотрел, отказаться от каких-то индексов мне сложно: они изначально
затачивались под конкретное рабочее место.

есть запрос с таким WHERE значит под него строим индекс. По
возможности частичный.

что не так в этом подходе?

--

. ''`.                               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