On 2024-07-04 22:18 +0200, Said Assemlal wrote: > +1 for this feature. Thanks!
> I noticed replacing the materialized view is blocking all reads. Is that > expected ? Even if there is a unique index ? That is expected because AccessExclusiveLock is acquired on the existing matview. This is also the case for CREATE OR REPLACE VIEW. My initial idea, while writing the patch, was that one could replace the matview without populating it and then run the concurrent refresh, like this: CREATE OR REPLACE MATERIALIZED VIEW foo AS ... WITH NO DATA; REFRESH MATERIALIZED VIEW CONCURRENTLY foo; But that won't work because concurrent refresh requires an already populated matview. Right now the patch either populates the replaced matview or leaves it in an unscannable state. Technically, it's also possible to skip the refresh and leave the old data in place, perhaps by specifying WITH *OLD* DATA. New columns would just be null. Of course you can't tell if you got stale data without knowing how the matview was replaced. Thoughts? -- Erik