Re: Avoid calling SetMatViewPopulatedState if possible - Mailing list pgsql-hackers

From cca5507
Subject Re: Avoid calling SetMatViewPopulatedState if possible
Date
Msg-id tencent_9FB090ACF6336552661A2FEC20D70E3B5405@qq.com
Whole thread
In response to Re: Avoid calling SetMatViewPopulatedState if possible  (David Geier <geidav.pg@gmail.com>)
List 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 by date:

Previous
From: Amit Langote
Date:
Subject: Re: Server crash: Use-after-free in AfterTriggerEndQuery()
Next
From: "cca5507"
Date:
Subject: Re: Call EndCopyFrom() after initial table sync in logical replication