PostgreSQL, indices
EXPLAIN ANALYZE в студию, зачем гадать?
Когда это действие производится у нас на посгрес 8 с ~20000 рядов, всё отлично, запрос жрёт менее миллисекунды.если время настолько мало — это означает, что таблица закеширована в памяти. И индекс, видимо, тоже.
Postgresql 8.3 заведомо умеет использовать для выборки по с1,с2,с4 индекс по c1,c2,c3.
Когда она же производится не у нас, на постгрес 7, ...В силу причин, единственный способ попытаться что-нибудь сделать дистанционно - это послать не к нам емейл с вежливой просьбой сделать то-то и то-то. Понятно, что попросить прислать структуру таблиц мы ещё можем, но не более.
Ехать не к нам тысячу километров очень не хочется. Особенно не хотелось бы в результате обнаружить, что действительно одной команды add index было бы достаточно. Это как-то неэффективно.
Вот я и спрашиваю как вообще индексы должны работать, хотя бы из общих соображений - могут ли они помогать при частичном совпадении колонок?
Вопрос: может ли причина состоять в том, что восьмой постгрес каким-то магическим образом умудряется использовать индекс для поиска неполных данных (т.е. если в индексе три колонки, а в запросе используется только две из них)может и, видимо, делает
Postgresql 8.3 заведомо умеет использовать для выборки по с1,с2,с4 индекс по c1,c2,c3.О, уже лучше! А где про это можно почитать и как это вообще называется по-английски?
О, уже лучше! А где про это можно почитать и как это вообще называется по-английски?http://www.postgresql.org/docs/8.3/interactive/indexes-multicolumn.html
а вообще, я верю что postgresql 7 умел тоже такое делать.
называется multicolumn index.
postgres docs, 11.3
postgres docs, 11.3
For example, given an index on (a, b, c) ....ну и там тонкости с тем, какие поля по порядку отсутствуют
This index could in principle be used for queries that have constraints on b and/or c with no constraint on a — but the entire index would have to be scanned, so in most cases the planner would prefer a sequential table scan over using the index.
Ох, ок, посмотрел, сравнил 8.3 с 7.4, да, по всей видимости суть именно в этом.
А это, я могу надеяться, что "порядок колонок" имеется в виду порядок вообще, нормализованный, а не в точности как в запросе?
То есть вообще на самом деле у нас фигня выглядит так:
index (a, b, c, d, e)
Обычный запрос - select blabla from x1, x2 where x1.a = x2.a and ... and x1.e = x2.e and x1.someothershit != x2.someothershit
Тормозные запросы -
select id from x1 where c = 'c' and d = 'd' and e = 'e' limit 1.
Так вот, мне как бы очень хочется ничего не сломать, но совсем уж фигню делать не хочется. Безопаснее всего, конечно, добавить ещё один индекс. Но можно сделать хитрый трюк - дропнуть этот и создать заново как (c, d, e, a, b). Так вот, нужно ли мне после этого исправлять порядок условий в запросах, или даже у старой версии хватит мозгов их переупорядочить?
(спасибо за помощь, кстати!)
А это, я могу надеяться, что "порядок колонок" имеется в виду порядок вообще, нормализованный, а не в точности как в запросе?
То есть вообще на самом деле у нас фигня выглядит так:
index (a, b, c, d, e)
Обычный запрос - select blabla from x1, x2 where x1.a = x2.a and ... and x1.e = x2.e and x1.someothershit != x2.someothershit
Тормозные запросы -
select id from x1 where c = 'c' and d = 'd' and e = 'e' limit 1.
Так вот, мне как бы очень хочется ничего не сломать, но совсем уж фигню делать не хочется. Безопаснее всего, конечно, добавить ещё один индекс. Но можно сделать хитрый трюк - дропнуть этот и создать заново как (c, d, e, a, b). Так вот, нужно ли мне после этого исправлять порядок условий в запросах, или даже у старой версии хватит мозгов их переупорядочить?
(спасибо за помощь, кстати!)
А это, я могу надеяться, что "порядок колонок" имеется в виду порядок вообще, нормализованный, а не в точности как в запросе?если это не так в седьмом — я очень сильно удивлюсь. порядок в запросе не должен ни на что влиять.
То есть вообще на самом деле у нас фигня выглядит так:index (a, b, c, d, e)Обычный запрос - select blabla from x1, x2 where x1.a = x2.a and ... and x1.e = x2.e and x1.someothershit != x2.someothershitТормозные запросы - select id from x1 where c = 'c' and d = 'd' and e = 'e' limit 1.т.е. один запрос по (a,b,c,d,e а другой — по (c,d,e)? тогда надо делать индекс по (c,d,e,a,b действительно.
Ок, спасибо.
Оставить комментарий
bleyman
Есть таблица с кучей данных.Есть индекс по колонкам c1, c2, c3 (обозначения условны).
В ходе некоей деятельности идут селекты по колонкам c1, c2, c4 (т.е. без c3). В смысле, тупо конструируется и посылается `select id from table where c1='xxx' and c2='yyy' and c4='zzz' limit 1` (причём подразумевается, что обычно эта фигня должна вернуть 0 рядов)
Когда это действие производится у нас на посгрес 8 с ~20000 рядов, всё отлично, запрос жрёт менее миллисекунды. Когда она же производится не у нас, на постгрес 7, со вроде бы такими же условиями (но точно уверенным в этом быть невозможно отжирается 250 миллисекунд.
Вопрос: может ли причина состоять в том, что восьмой постгрес каким-то магическим образом умудряется использовать индекс для поиска неполных данных (т.е. если в индексе три колонки, а в запросе используется только две из них а седьмой — нет? И, если да, как будет правильно поступить: просто добавить ещё один индекс, теперь по нужным колонкам?