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 использовать НУЖНЫЙ индекс?
|
Список | pgsql-ru-general |
Я бы ещё крепко задумался о снижении количества индексов. Например, сам по себе
"driver_work_index" btree (did, status)
WHERE status = ANY (ARRAY['confirm'::text, 'accept'::text, 'driving'::text, 'waiting'::text, 'transporting'::text])
— странный. Зачем пихать status вторым слоем, и одновременно фильровать? Не вижу смысла."driver_work_index" btree (did, status)
WHERE status = ANY (ARRAY['confirm'::text, 'accept'::text, 'driving'::text, 'waiting'::text, 'transporting'::text])
Индекс по (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 по дате отправления: