|
Модераторы: skyboy |
|
polin11 |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 122 Регистрация: 6.6.2015 Репутация: нет Всего: нет |
Есть запрос, использую СУБД Postgres
В базе есть индекс по полю Field1 и составной индекс по 2 полям (Field2 и Field3). Если в запросе указать ограничение LIMIT, то используется индекс по полю Field1 и потребляется много ресурсов. Если в запросе убрать ограничение LIMIT, то используется составной индекс (Field2 и Field3) ресурсов тратиться в 2 раза меньше, но время выполнения запроса в несколько раз больше. Вопрос можно ли в запросе оставить LIMIT 100 и обязать Postgres использовать составной индекс? |
|||
|
||||
Akina |
|
|||
Советчик Профиль Группа: Модератор Сообщений: 20570 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 45 Всего: 453 |
Увы, в постгрессе нет такой штуки как index hints. Как нет и INCLUDE.
-------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
Snowy |
|
|||
Эксперт Профиль Группа: Модератор Сообщений: 11363 Регистрация: 13.10.2004 Где: Питер Репутация: 1 Всего: 484 |
|
|||
|
||||
polin11 |
|
||||||
Шустрый Профиль Группа: Участник Сообщений: 122 Регистрация: 6.6.2015 Репутация: нет Всего: нет |
Если добавить
то нужно менять запрос на
то используется составной индекс (Field2 и Field3), но время выполнения также увеличивается в несколько раз, даже просто Например, если изменить запрос на
то используется составной индекс (Field2 и Field3), но время выполнения также увеличивается в несколько раз |
||||||
|
|||||||
Snowy |
|
|||
Эксперт Профиль Группа: Модератор Сообщений: 11363 Регистрация: 13.10.2004 Где: Питер Репутация: 1 Всего: 484 |
1. Не используй limit без order by
2. Не пользуйся distinct, если в выборке больше 1000+ записей. Это очень медленная операция. Замени на group by, вложенный селект с limit 1, агрегатные функции, рекурсивные запросы, оконные функции. Что угодно, но не distinct. Особенно, если у тебя текстовые данные. distinct применим только на малых выборках. На больших вызывает бешенный сиквенсскан по всему результату. И вообще лучше никогда не использовать distinct, distinct on и IN. 3. А тебе действительно нужен составной индекс? У Field3 так много вариаций? Если вариантов не больше 10, то может обойтись просто индексом по Field2? 4. Увеличь shared_buffers и work_mem в настройках postgres.conf - на дефолтных значениях далеко не уедешь. Особенно с дистинктом или вложенными запросами. Больше памяти позволит уменьшить фрагментарность запросов и ускорит большие выборки в разы. Как вариант:
|
|||
|
||||
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | Составление SQL-запросов | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |