On 05.05.2026 13:58, cca5507 wrote:
>> While being a simple patch, it would be good to know what actual use
>> cases this change improves on and by how much. Can you share a test case
>> and/or performance data?
>
> The improvement of performance is small, so it's hard to observe it. But I think
> the patch is still useful because we can avoid generating dead pg_class tuple:
>
> create table t(a int);
> create materialized view m as select a from t;
> create unique index on m(a);
> select ctid from pg_class where relname = 'm';
> refresh materialized view concurrently m;
> select ctid from pg_class where relname = 'm';
>
> Before the patch, the ctid will change every time we refresh the matview.
Yeah, that's kind of what I had in mind as I wasn't expecting the
performance to matter much here. Avoiding the bloat seems generally
reasonable.
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'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.
--
David Geier
