From: | Tobias McNulty <tobias(at)caktusgroup(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | documentation question regarding REFRESH MATERIALIZED VIEW CONCURRENTLY |
Date: | 2025-02-23 01:57:52 |
Message-ID: | CAMGFDKTW+SgLgdqRNa4cx9x1rFbA=2_8SE51r30A8o+9N2ikpA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hello,
The documentation [1] for REFRESH MATERIALIZED VIEW states that the
"CONCURRENTLY" parameter:
> Refresh[es] the materialized view without locking out concurrent selects on the materialized
> view. Without this option a refresh which affects a lot of rows will tend to use fewer
> resources and complete more quickly, but could block other connections which are trying to
> read from the materialized view. This option may be faster in cases where a small number
> of rows are affected.
I can read the phrase "affects a lot of rows" in two ways.
Specifically, either that (1) the refresh operation actually updates
the contents of a lot of rows in the materialized view, or (2) that
the materialized view itself contains a lot of rows, regardless of
whether or not they change with each refresh.
Could someone knowledgeable in this area possibly clarify which of
these is the correct interpretation, or if there is another
interpretation I may be missing?
Thanks in advance for your help.
Tobias
[1] https://www.postgresql.org/docs/17/sql-refreshmaterializedview.html
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Sabino Mullane | 2025-02-23 15:21:14 | Re: documentation question regarding REFRESH MATERIALIZED VIEW CONCURRENTLY |
Previous Message | Alicja Kucharczyk | 2025-02-22 20:55:34 | Re: Azure Database for PostgreSQL flexible server vs other Azure offerings |