Для чего нужен Materialized View в PostgreSQL?

Обычное представление (VIEW) в PostgreSQL — это просто сохранённый запрос: каждый раз, когда вы к нему обращаетесь, СУБД выполняет его заново. Если запрос содержит тяжёлые агрегации, соединения больших таблиц или оконные функции, это может занимать секунды и сильно нагружать базу. Materialized View решает эту проблему, сохраняя результат запроса как реальную таблицу на диске.

Как это работает

При создании материализованного представления PostgreSQL выполняет запрос один раз и записывает результат в отдельную физическую таблицу. Последующие SELECT'ы читают уже готовые данные, что даёт огромный прирост скорости. Однако данные становятся «снимком» на момент последнего обновления.

Пример использования

Допустим, есть таблица заказов, и нужно быстро получать суммарную выручку по дням для дашборда:

CREATE MATERIALIZED VIEW daily_revenue AS
SELECT date_trunc('day', created_at) AS day,
       SUM(amount) AS total
FROM orders
GROUP BY 1;

-- Быстрое чтение готовых данных
SELECT * FROM daily_revenue WHERE day > now() - interval '7 days';

-- Обновление данных (блокирует чтение)
REFRESH MATERIALIZED VIEW daily_revenue;

-- Обновление без блокировки чтения
REFRESH MATERIALIZED VIEW CONCURRENTLY daily_revenue;

Ключевые особенности

• Данные не обновляются автоматически — нужен REFRESH по расписанию (cron, pg_cron) или по триггеру.
• CONCURRENTLY требует уникального индекса, но позволяет читать во время обновления.
• Можно создавать индексы на материализованном представлении, как на обычной таблице.
• Занимает место на диске, равное объёму результата.

Когда применять

Materialized View стоит использовать для отчётов, дашбордов и аналитики, где данные могут быть слегка устаревшими, а скорость чтения критична. Если нужна актуальность в реальном времени — лучше подойдут обычные VIEW, индексы или кэширование на уровне приложения.