| От | cca5507 |
|---|---|
| Тема | Re: Avoid calling SetMatViewPopulatedState if possible |
| Дата | |
| Msg-id | tencent_9FB090ACF6336552661A2FEC20D70E3B5405@qq.com обсуждение |
| Ответ на | Re: Avoid calling SetMatViewPopulatedState if possible (David Geier <geidav.pg@gmail.com>) |
| Список | pgsql-hackers |
> But refreshing a materialized view doesn't only change relispopulated > but also columns like relfilenode, relpages, relhasindex, etc. Doesn't > changing these columns during REFRESH MATERIALIZED VIEW make your > optimization applicable in a lot less cases? I don't think so. If we can skip SetMatViewPopulatedState(), we avoid generating a dead pg_class tuple in all cases. > I'm actually wondering why it works at all, even in the example you > gave. Because I thought that even when nothing has changed the pg_class > row is updated for more columns than just relispopulated. "refresh materialized view concurrently" is done by doing DELETE + INSERT to the matview directly, so only relispopulated will change before the patch. After the patch, the pg_class row don't change anymore. -- Regards, ChangAo Chen
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера