Re: postgres materialized view refresh performance

> My understanding is that when CONCURRENTLY is specified, Postgres implements the refresh as a series of INSERT,
UPDATE,
> and DELETE statements on the existing view. So the answer to your question is no, Postgres doesn’t create another
tableand 
> then swap it.

The INSERTS/UPDATE/DELETE happens only for the difference.  PG first creates a new temp table and then compares it with
the MV and detects the difference.  That is why for CONCURRENTLY, a unique index is required on the MV.