Функция в одном сеансе с параметрами diff становится все медленнее - PullRequest
0 голосов
/ 19 июня 2020

Проблема:

PostgreSQL 12.2 (Ubuntu 12.2-2.pgdg18.04 + 1) на x86_64-p c - linux -gnu, скомпилировано g cc (Ubuntu 7.4 .0-1ubuntu1 ~ 18.04.1) 7.4.0, 64-разрядный

Клиент - это Data Grip и такое же поведение на моем сервере отчетов, который использует драйвер, поставляемый с Jaspersoft

Я запускаю одна и та же функция для создания отчетов с разными параметрами несколько раз за один сеанс. То же самое и с теми же параметрами.

Они выполняются один за другим, а не одновременно.

Результат имеет только несколько строк, но читается из довольно несколько таблиц, без записи.

Это просто объединение таблиц и отсутствие выбора входных данных или обновлений для самих таблиц (хотелось бы иметь возможность отправлять запросы, но не могу по соображениям безопасности).

После того, как я запустил функцию несколько раз, она начинает тормозить и достигает неприемлемого уровня. Например, одна из функций работает с 1 секунды до более 90+ секунд (именно здесь я остановил тестирование).

Устранение неполадок:

Я перешел на сервер и завершил сеанс, а затем что он начинает нормально работать в течение нескольких прогонов.

Стандартный отчет действительно использует временную таблицу, но я удалил ее для тестирования. Я выполнил следующее после того, как у него возникла проблема, чтобы попытаться решить проблему.

VACUUM все затронутые таблицы; - Я знаю, что этого не требуется, поскольку в эти таблицы нет серьезных изменений, но я пробовал практически все. Язык plpg sql.

SET SESSION AUTHORIZATION DEFAULT;
RESET ALL;
DEALLOCATE ALL;
CLOSE ALL;
UNLISTEN *;
SELECT pg_advisory_unlock_all();
DISCARD PLANS;
DISCARD SEQUENCES;
DISCARD TEMP;

Кажется, не существует хорошего способа завершить незанятые соединения без отдельного приложения или сценария, выполняемого через задание.

1 Ответ

0 голосов
/ 24 июня 2020

Оказывается, существует известная проблема, но редко упоминается проблема с параметрами в планах выполнения, когда, начиная с 6-го запуска в том же сеансе, запускается намного больше времени. Решение состоит в том, чтобы просто установить план выполнения на force_custom_plan, и он работает нормально или работал в моем случае.

ALTER FUNCTION xy SET plan_cache_mode = force_custom_plan;

...