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