> Я бы ещё крепко задумался о снижении количества индексов. Например, сам по себе
> "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