Один и тот же тяжелый запрос может выполняться десятки, сотни или тысячи раз.

Например, дашборд пересчитывает агрегаты, приложение проверяет права пользователя, каталог считает количество страниц, а 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, где он помогает разгрузить базу и какие ограничения важно учитывать.

💬 Читайте нас в MAX