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])

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

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

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

2016-01-26 13:12 GMT+03:00 Dmitry E. Oboukhov <unera(at)debian(dot)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(at)debian(dot)org jabber://UNera(at)uvw(dot)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-----
>
>