public inbox for [email protected]  

help / color / mirror / Atom feed

From: =?utf-8?B?Y2NhNTUwNw==?= <[email protected]>
To: =?utf-8?B?RGF2aWQgR2VpZXI=?= <[email protected]>
To: =?utf-8?B?cGdzcWwtaGFja2Vycw==?= <[email protected]>
Subject: Re: Avoid calling SetMatViewPopulatedState if possible
Date: Fri, 8 May 2026 10:27:02 +0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

> 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

view thread (8+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Avoid calling SetMatViewPopulatedState if possible
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox