| From: | Philip Semanchuk <philip(at)americanefficient(dot)com> |
|---|---|
| To: | Ravi Krishna <sravikrishna(at)mail(dot)com> |
| Cc: | Ayub M <hiayub(at)gmail(dot)com>, PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: postgres materialized view refresh performance |
| Date: | 2020-10-23 14:53:07 |
| Message-ID: | FE04128F-9905-4917-925B-0BCF6EC70804@americanefficient.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
> On Oct 23, 2020, at 9:52 AM, Ravi Krishna <sravikrishna(at)mail(dot)com> wrote:
>
>> 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 table and
>> 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.
Yes, thank you, that’s what I understand too but I expressed it very poorly.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PALAYRET Jacques | 2020-10-23 15:14:50 | Re: Conditional column filtering with pglogical replication |
| Previous Message | Fabrízio de Royes Mello | 2020-10-23 14:23:19 | Re: Conditional column filtering with pglogical replication |