Одновременная ссылка на материализованное представление sh занимает значительно больше времени, чем не одновременная

Question

У меня есть материализованное представление, которое объединяет 5 таблиц (которые находятся вне моего контроля) с некоторой оптимизацией, работающей на Postgres БД. В таблице около 30-40 миллионов строк. Это материализованное представление необходимо обновлять один раз в день (после полуночи), так как новые данные добавляются / обновляются в этих 5 таблицах. Есть около 50-150 тысяч обновленных строк, которые нужно обновлять в режиме просмотра матов каждый день.

Вот проблема, когда я переосмысливаю sh материализованное представление без одновременного выполнения, оно выполняется примерно за 25-35 минут. Тем не менее, когда вы делаете это одновременно, это занимает около 15 часов! тот с индексами упал. Интересно, чего ожидать, и что я должен устранять в этом сценарии? Я установил для work_mem значение 500 МБ в ОЗУ объемом 2 ГБ, а для IOPS - 2000 для RDS.

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

Answer 1

Такое поведение, когда refre sh может занять больше времени с CONCURRENT, следует ожидать, так как база данных позволяет другим пользователям запрашивать материализованное представление во время fre sh. Обычно он работает быстрее без одновременного (считают это выделенным процессом) и использует меньше ресурсов, но не позволяет другим взаимодействовать с представлением во время refre sh. Вы можете прочитать больше здесь .

Может быть проще разрешить время простоя во время refre sh. Однако, если запрашивать представление во время refre sh важно, и вы не хотели бы продолжать использовать встроенную функциональность, вы могли бы рассмотреть более сложный подход к созданию индексов для разделов (например, ежедневных загрузок), ручному выполнению вставок и обеспечению ваши запросы получают данные на основе последнего доступного раздела (например, WHERE CURRENT_DATE - целое число «1»). Эта дополнительная нагрузка может быть автоматизирована.

Answer 2

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

Тогда можно получить «быстрое» построение материализованного представления. и все еще получить доступ к старой версии, пока вы строите. Недостатком является то, что вам потребуется больше места для хранения.