| From: | cca5507 <cca5507(at)qq(dot)com> |
|---|---|
| To: | David Geier <geidav(dot)pg(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Avoid calling SetMatViewPopulatedState if possible |
| Date: | 2026-05-08 02:27:02 |
| Message-ID: | tencent_9FB090ACF6336552661A2FEC20D70E3B5405@qq.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | cca5507 | 2026-05-08 02:34:56 | Re: Call EndCopyFrom() after initial table sync in logical replication |
| Previous Message | Amit Langote | 2026-05-08 00:55:19 | Re: Server crash: Use-after-free in AfterTriggerEndQuery() |