|
Модераторы: LSD |
|
polin11 |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 122 Регистрация: 6.6.2015 Репутация: нет Всего: нет |
Использую СУБД Postgresql, относительно не так давно, SQL запросы стали выполняться намного дольше по времени. Некоторые запросы выполняются в несколько десятков раз дольше.
Провел анализ работы БД (сравнил с данными месячной давности), проблем с памятью или процами нет. Но заметил что время доступа к разделу с БД различается на порядок, что можно с эти сделать, кроме банального VACUUM FULL ANALYZE? |
|||
|
||||
polin11 |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 122 Регистрация: 6.6.2015 Репутация: нет Всего: нет |
В запросе стал использоваться другой индекс, правильно ли я понимаю, после
VACUUM FULL ANALYZE должна обновиться статистика, которую использует планировщик для выбора оптимального способа выполнения запроса, также должен помочь REINDEX? Есть ли еще способ кроме VACUUM FULL ANALYZE поставить на путь истинный планировщик? |
|||
|
||||
Snowy |
|
|||
Эксперт Профиль Группа: Модератор Сообщений: 11363 Регистрация: 13.10.2004 Где: Питер Репутация: нет Всего: 484 |
Это естественный жизненный цикл - по мере накопления информации в таблице, может меняться план запроса.
Правильное решение - оптимизировать запрос, который стал работать плохо. Таблица в будущем вряд ли будет становиться меньше. Возможно запросу не хватает памяти для использования прежнего индекса. Можно увеличить параметр work_mem в конфиг файле. Можно удалить неэффективный индекс и построить новый, возможно составной. |
|||
|
||||
polin11 |
|
||||||
Шустрый Профиль Группа: Участник Сообщений: 122 Регистрация: 6.6.2015 Репутация: нет Всего: нет |
К сожалению VACUUM и REINDEX не помогли.
Как работает планировщик POSTGRES, для меня загадка. Есть такая же БД(тестовая, с аналогичным набором данных) на другом сервере, в аналогичных запросах, там используется нужный индекс, который раньше использовался на проблемной базе. Приведу элементарный запрос и планы выполнения
План запроса на проблемной БД:
Используется Index1 по полю Field2 с классом оператора varchar_pattern_ops, запрос выполнялся 25 секунд С аналогичной БД на другом сервере
Используется Index2 по полям (Field2 с классом оператора varchar_pattern_ops, Field3), запрос выполнялся 50 миллисекунд Как-то оптимизировать запрос нельзя, куда уж проще. У меня осталась последняя мысль, удалить Index1, но будет ли во всех местах, где действительно нужен Index1, использоваться Index2 и не будет ли он тормозить эти запросы? Буду рад любым конструктивным идеям |
||||||
|
|||||||
Snowy |
|
||||||
Эксперт Профиль Группа: Модератор Сообщений: 11363 Регистрация: 13.10.2004 Где: Питер Репутация: нет Всего: 484 |
Неисповедимы пути планировщика.
В 9-й версии его улучшили. Рекомендую обновить до 10+, если это непринципиально. Поиск по полю 2 вполне может использовать Index2 и без второго условия. Так что, если где-то и упадёт производительность, то незначительно. Так что достаточно смело можно удалять. Ещё варианты: Сделать копию базы и провести опыты:
По примеру неочевидно, но, если нужен поиск именно по первым двум символам, то рекомендую убрать like и использовать полное равенство:
Попытаться заставить следовать прежним рекомендациям:
Если копия базы ведёт себя неаналогично, то можно и на живой базе пробовать. Только отключить автокоммит или включить автороллбэк. И после опытов сделать вакуум. |
||||||
|
|||||||
polin11 |
|
||||||
Шустрый Профиль Группа: Участник Сообщений: 122 Регистрация: 6.6.2015 Репутация: нет Всего: нет |
Как можно скрыть оп планировщика поле Field2, чтобы использовался индекс по Fileld3. В запросе
В поле Field2 в нижнем регистре тип данных text Вариант 1:
Вариант 2:
Может есть варианты более оптимальные? |
||||||
|
|||||||
polin11 |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 122 Регистрация: 6.6.2015 Репутация: нет Всего: нет |
помогли следующие волшебные команды
ALTER TABLE "Table1" ALTER COLUMN "Field2" SET STATISTICS 10000; VACUUM ANALYZE "Table1"; Спасибо за помощь Snowy!!!! |
|||
|
||||
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | PostgreSQL | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |