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

Поиск
Список
Период
Сортировка
От Nikolay Samokhvalov
Тема Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] Снова подниму вопрос: как заставить pg использовать НУЖНЫЙ индекс?
Дата
Msg-id CANNMO+K2mVNgTd5DYqtttWrOfS-5ELZJGuUQ33ChOo+s92b6+w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [pgsql-ru-general] Снова подниму вопрос: как заставить pg использовать НУЖНЫЙ индекс?  (Oleg Bartunov <obartunov@gmail.com>)
Ответы Re: Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] Снова подниму вопрос: как заставить pg использовать НУЖНЫЙ индекс?  ("Dmitry E. Oboukhov" <unera@debian.org>)
Список pgsql-ru-general
Дерево обсуждения
Я бы ещё крепко задумался о снижении количества индексов. Например, сам по себе
"driver_work_index" btree (did, status)
     WHERE status = ANY (ARRAY['confirm'::text, 'accept'::text, 'driving'::text, 'waiting'::text, 'transporting'::text])

— странный. Зачем пихать status вторым слоем, и одновременно фильровать? Не вижу смысла.

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

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

2016-01-26 13:12 GMT+03:00 Dmitry E. Oboukhov <unera@debian.org>:
> Олег, а смысл? Ну будет 1 индекс скан — и всё.
> Тут проблема в том, что есть уже btree по (gid, sid, ...), полный и при
> построении частичного планнер его почему-то видеть не хочет.

> Можно попробовать нечто совсем ненаучное, чтобы заставить частичный индекс
> заработать, — поправить запрос:

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


> И в частичный индекс тоже 'smthnotexisting' засунуть.

спасибо, интересная мысль.

я некоторые запросы заставлял использовать индекс прописывая помимо
WHERE еще и ORDER BY как в индексе. Иногда помогает ему выбрать нужный
индекс. Но если он выберет не тот, то ORDER BY усугублять будет
ситуацию.

ща посмотрю можно ли собрать хинт к планеру для моего постгриса.


--

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEAREDAAYFAlanRo0ACgkQq4wAz/jiZTc2lgCgkXbGysNHYJNA4d9DQn9KrWKM
hv8AoIdmlkm6/ge9MjWt5Woze7qbZjCw
=zp0u
-----END PGP SIGNATURE-----


В списке pgsql-ru-general по дате отправления:

Предыдущее
От: "Dmitry E. Oboukhov"
Дата:
Сообщение: Re: Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] Снова подниму вопрос: как заставить pg использовать НУЖНЫЙ индекс?
Следующее
От: "Dmitry E. Oboukhov"
Дата:
Сообщение: Re: Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] Снова подниму вопрос: как заставить pg использовать НУЖНЫЙ индекс?