Кэш результатов запросов в Postgres Pro: как ускорить часто выполняющиеся запросы и разгрузить базу

[danolivo]

Здесь самый главный вопрос даже не инвалидация кэша, а насколько часто в БД встречаются абсолютно идентичные запросы, с идентичными константами? Если часто, то может приложению стоит просто самостоятельно запомнить результат?

Ну и да, зависимость от вероятности попасть на коллизию хэшей врядли добавляет DBA спокойствия …

[pda0]

В MySQL, кстати, кеш запросов считается устаревшим и, по моему, с какой-то версии его вообще удалили.

[danolivo]

Да, держать на стороне СУБД кэш результатов конкретных запросов - это странная идея. Вот автоматом создавать MATERIALIZED VIEW, чтобы потом их использовать в других запросах - вот это была бы тема!

[Ptalomej]

Весь этот функционал это полная чушь с одними минусами, это добавлять квери хинты в приложение его усложняет, а не использование кэша, который может быть любым, без всяких сложностей и гораздо более гибким чем в постгресс

[slonik_pg]

Внешний кэш — это, возможно, гибкий инструмент, когда нужно кэшировать объекты бизнес-логики, сессии или API-ответы целиком. Но если цель — защитить базу данных от повторяющихся тяжелых SQL-запросов (например, для дашбордов или справочников), то pgpro_result_cache позволяет сделать это добавлением одного комментария в SQL-строку, избавляя от необходимости поднимать отдельный сервис, сериализовать данные и, самое главное, вручную писать сложнейшую логику инвалидации кэша при обновлении таблиц. Это не замена внешнему кэшу, это эффективный инструмент другого уровня