Наткнулся на ваш комментарий, возможно у меня какое-то базовое непонимание. А чем плох Index Scan? Или "на хватает подходящего индекса" имеется ввиду "не хватает покрывающего индекса"?
Раз уж зашла речь о pgBadger спрошу. Если включен auto_explain и план пишет в логи, в отчет pgBadger должен explain попадать? У меня почему то не попадает.
Забыл сказать, что такое поведение заметили после апгрейда версии с Postgres PRO 11.7 Ent на Postgres PRO 15.1.10. Долго сидели над этим, игрались с параметрами, но с помощью параметров купировать это не удалось.
1) Статистика актуальна, таблицы довольно горячие и с обновлением статистики неплохо справляется autovacuum analyze. Дело в чем-то другом, пока не понимаю в чем.
2) К сожалению, нету доступа к коду приложения чтобы SET сделать.
3) Все таки hint? Я почему то больше склонялся к sr_plan.
Если ни первое, ни второе, ни третье, то тогда рефакторинг запроса?
Здравствуйте, спасибо, интересно было почитать про выбор метода в зависимости от сложности. Скажите, как поступать в случае, если есть допустим запрос где используется куча JOIN и подзаросов. В определенном месте плана планировщик выбирает nested loop. Запрос длится 1 час. Как только отключаешь через SET enable_nestedloop = off, время запроса сокращается до 13 сек. Такие запросы только переписывать?
Вот тут призадумался. Видел у авторов в блогах, точно сейчас не скажу. Во всяком случае, вряд ли кому-то понравится что в таблице например 50% мертвых строк, особенно, если эта таблица большая. Задокументированная величина вряд ли есть, да она вряд ли может существовать, не даром настройки гибкие. А какие у вас критерии правильной настройки autovacuum?
Всегда считал что не должно быть высоким значение n_dead_tup у таблиц. Например, не более 20%. А то вдруг так во всех таблицах мертвых таплов больше чем живых, тогда конечно с настройками autovacuum что-то не то.
Можете сказать, чем так плох pg-pool? Уже не первый раз вижу о нем такое мнение.
Наткнулся на ваш комментарий, возможно у меня какое-то базовое непонимание. А чем плох Index Scan? Или "на хватает подходящего индекса" имеется ввиду "не хватает покрывающего индекса"?
Да нет. Вот команда которой выгружаю:
pgbadger -j6 -a1 -s10 -t50 -f stderr postgresql-2025-01-24.log -o pg_log_24012025.htmlТак же вертел-крутил log_line_prefix, ничего этим не добился. Не попадает explain в отчет и все тут.
Раз уж зашла речь о pgBadger спрошу. Если включен auto_explain и план пишет в логи, в отчет pgBadger должен explain попадать? У меня почему то не попадает.
Забыл сказать, что такое поведение заметили после апгрейда версии с Postgres PRO 11.7 Ent на Postgres PRO 15.1.10. Долго сидели над этим, игрались с параметрами, но с помощью параметров купировать это не удалось.
1) Статистика актуальна, таблицы довольно горячие и с обновлением статистики неплохо справляется autovacuum analyze. Дело в чем-то другом, пока не понимаю в чем.
2) К сожалению, нету доступа к коду приложения чтобы SET сделать.
3) Все таки hint? Я почему то больше склонялся к sr_plan.
Если ни первое, ни второе, ни третье, то тогда рефакторинг запроса?
Здравствуйте, спасибо, интересно было почитать про выбор метода в зависимости от сложности. Скажите, как поступать в случае, если есть допустим запрос где используется куча JOIN и подзаросов. В определенном месте плана планировщик выбирает nested loop. Запрос длится 1 час. Как только отключаешь через SET enable_nestedloop = off, время запроса сокращается до 13 сек. Такие запросы только переписывать?
Вот тут призадумался. Видел у авторов в блогах, точно сейчас не скажу. Во всяком случае, вряд ли кому-то понравится что в таблице например 50% мертвых строк, особенно, если эта таблица большая. Задокументированная величина вряд ли есть, да она вряд ли может существовать, не даром настройки гибкие. А какие у вас критерии правильной настройки autovacuum?
Имеется ввиду слишком часто или слишком редко?
Всегда считал что не должно быть высоким значение n_dead_tup у таблиц. Например, не более 20%. А то вдруг так во всех таблицах мертвых таплов больше чем живых, тогда конечно с настройками autovacuum что-то не то.