Материализованный отчёт блокирует чтение: требования к CONCURRENTLY

Тяжёлый отчёт вынесли в materialized view, и страницы стали открываться быстро. Затем по расписанию запускается REFRESH, а читатели ждут обновления. Нужен способ пересчитать сохранённый результат, сохранив возможность его читать.

REFRESH MATERIALIZED VIEW CONCURRENTLY обновляет представление без исключения обычных SELECT. Для него представление должно быть заполнено и иметь подходящий UNIQUE индекс: по обычным столбцам, охватывающий все строки, без WHERE и выражений.

Как изменить решение

CREATE MATERIALIZED VIEW daily_sales AS
SELECT order_day, channel, sum(amount) AS revenue
FROM sales_fact
GROUP BY order_day, channel;
CREATE UNIQUE INDEX daily_sales_key
ON daily_sales (order_day, channel);
REFRESH MATERIALIZED VIEW CONCURRENTLY daily_sales;

Пара order_day, channel задаёт зерно результата. Индекс одновременно документирует это зерно и позволяет сопоставлять строки при конкурентном обновлении. Если эти поля допускают NULL, отдельно проверьте семантику ключа и необходимость обязательных значений.

CONCURRENTLY не превращает полный пересчёт в инкрементальный. Исходный запрос всё равно нужно выполнить, а база делает дополнительную работу для обновления результата. Если агрегат огромен и меняется только текущий день, стоит сравнить этот путь с отдельной таблицей витрины и явной загрузкой изменяемых периодов.

Что проверить на своих данных

В тестовом окружении удерживайте чтение представления и запустите обычный REFRESH, затем конкурентный. Отдельно попробуйте CONCURRENTLY без уникального индекса, чтобы увидеть причину отказа. Проверьте итоговую сумму против исходного запроса после завершения обновления.

У отчёта должен быть понятный момент свежести. Успешный запуск расписания не равен успешному завершению REFRESH, поэтому храните время последнего завершённого обновления. Два одновременных обновления одного представления тоже не дают параллельного ускорения: для него допускается только один REFRESH за раз. Планировщик задач должен учитывать это при повторных запусках.

Практика дальше

Если отчёту уже нужен собственный цикл обновления, полезно спроектировать загрузку целиком. На Data Engineering Fast-Track вы связываете Kafka, Spark, lakehouse и Airflow, добавляете зависимости и проверки свежести. Итоговый проект объединяет эти части в локальный конвейер.

Посмотреть программу и практику курса

Источник: Материализованный отчёт блокирует чтение — официальная документация.

Другие задачи по теме: PostgreSQL: запись, блокировки и планы запросов.