Комментарии 14
А, хинты в pg завезли!
SELECT /*+ MergeJoin(a b) */ *
FROM pgbench_branches b
JOIN pgbench_accounts a ON b.bid = a.bid
ORDER BY a.aid;
Доступно только в pro версии?
Расширение pg_hint_plan с открытым исходным кодом и совместимо со всеми поддерживаемыми версиями PostgreSQL. Инструкция по установке из официального репозитория
В Pro версию тоже входит, поэтому русскоязычная документация по модулю расположена в разделе enterprise
[сообщение боли]
Блин... Как же далёк постгрес от нормальных продуктов где из коробки есть то, что тут или нет или приседать надо чтобы получить подобие.
Блин2... но вынужден изучать его нюансы и читать за него ибо вопрос о его использовании решён(не нами-разработчиками) в компании.
[/сообщение боли]
Вместо log_min_duration_statement советую pg_store_plans
https://ossc-db.github.io/pg_store_plans/ все таки родной sql , это гораздо удобнее чем запись планов в логфайл (особенно, если у вас приличные нагрзуки).
И (позвольте немного попиарюсь) к этому , еще прикрутил историю сессий - https://habr.com/ru/companies/uzum/articles/865622/ , и получил практически awr оракловый ). Так что можно жить и с Postgres, просто тут принцип другой, минимум - из коробки.
Спасибо!
В тему сохранения долгих запросов (и не только) могу добавить рекомендацию почитать про pg_profile. А для облегчения чтения логов - pgBadger.
Вдруг кому-нибудь окажется полезным.
Раз уж зашла речь о pgBadger спрошу. Если включен auto_explain и план пишет в логи, в отчет pgBadger должен explain попадать? У меня почему то не попадает.
Может, установлен флаг?--noexplain : do not process lines generated by auto_explain
Здравствуйте, спасибо, интересно было почитать про выбор метода в зависимости от сложности. Скажите, как поступать в случае, если есть допустим запрос где используется куча JOIN и подзаросов. В определенном месте плана планировщик выбирает nested loop. Запрос длится 1 час. Как только отключаешь через SET enable_nestedloop = off, время запроса сокращается до 13 сек. Такие запросы только переписывать?
Не обязательно. Тут может быть несколько подходов:
1) Если планировщик не оптимально выбрал метод из-за устаревшей статистики по некоторой таблице, может помочь своевременный запуск ANALYSE по этой таблице перед запуском запроса. Часто его использовать не стоит - может долго выполняться, но с некоторой периодичностью может быть полезно.
2) Раз выяснили, что отключение Nested Loop хорошо работает для этого запроса (несмотря на большое число операций в нём), можно «прилепить» этот SET к запросу (SET LOCAL внутри транзакции).
3) Самый элегантный способ, чтобы не переписывать запрос и не делать дополнительных действий: добавить к нему hint.
Забыл сказать, что такое поведение заметили после апгрейда версии с Postgres PRO 11.7 Ent на Postgres PRO 15.1.10. Долго сидели над этим, игрались с параметрами, но с помощью параметров купировать это не удалось.
1) Статистика актуальна, таблицы довольно горячие и с обновлением статистики неплохо справляется autovacuum analyze. Дело в чем-то другом, пока не понимаю в чем.
2) К сожалению, нету доступа к коду приложения чтобы SET сделать.
3) Все таки hint? Я почему то больше склонялся к sr_plan.
Если ни первое, ни второе, ни третье, то тогда рефакторинг запроса?
mean_exec_time — среднее время выполнения запроса;
В данном случае, есть одна серьезная проблема - "среднее арифметическое" неустойчиво к выбросам. А выбросы в продуктивной СУБД и особенно в облаках - это норма.
В результате - возможны аномалии. Например , встретил такое :
https://dzen.ru/a/Z1--cZ4sHEmzLsy5
Поэтому, данный показатель использовать при анализе запросов в продуктивном контуре - рискованно. Можно потратить время на поиск проблемы там где проблемы в общем то и нет.
Как поймать и обезвредить проблемные запросы в PostgreSQL