Один и тот же тяжелый запрос может выполняться десятки, сотни или тысячи раз. — 1 июня 2026 г. в 12:17:23.397
Один и тот же тяжелый запрос может выполняться десятки, сотни или тысячи раз. Например, дашборд пересчитывает агрегаты, приложение проверяет права пользователя, каталог считает количество страниц, а BI-система запрашивает метаданные схемы. Если результат не меняется, база все равно каждый раз тратит ресурсы: читает данные, строит план, выполняет соединения и считает агрегаты. Для таких сценариев в Postgres Pro Enterprise есть расширение pgpro_result_cache. Оно сохраняет результат запроса в общей памяти экземпляра кластера. При повторном выполнении сервер не считает запрос заново, а сразу отдает готовый результат из кэша. Это полезно, когда запрос выполняется часто, обрабатывает много данных, но возвращает небольшой результат. Например: 🔹 Агрегаты для отчетов и дашбордов. 🔹 Счетчики для пагинации. 🔹 Справочники и проверки прав. 🔹Частые запросы к системному каталогу. 🔹 Метаданные, которые запрашивают ORM, BI-системы и пулы соединений. Такой кэш можно реализовать на стороне приложения, но это усложняет код. Разработчикам нужно синхронизировать данные между сессиями, следить за актуальностью результатов и отдельно продумывать логику сброса. pgpro_result_cache переносит эту задачу на уровень СУБД. Расширение включается параметром конфигурации, а конкретный запрос попадает в кэш только по явному хинту /*+result_cache*/. Поэтому механизм не пытается кэшировать все подряд: разработчик сам выбирает запросы, для которых это действительно полезно. У кэша есть TTL, мониторинг через pgpro_result_cache_data и режим согласованного кэша pgpro_result_cache.consistent = on. В этом режиме расширение автоматически сбрасывает зависимые записи при DML- и DDL-операциях. При этом кэш не работает как универсальная кнопка ускорения. Очень быстрые запросы иногда выгоднее выполнить заново, чем искать результат в кэше. Если в базе используются политики RLS, тоже нужен особый контроль: кэшированные результаты их игнорируют. 🔗 Читайте на Хабре, как устроен pgpro_result_cache, где он помогает разгрузить базу и какие ограничения важно учитывать.