Thread: documentation question regarding REFRESH MATERIALIZED VIEW CONCURRENTLY

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

On Sun, Feb 23, 2025 at 10:21 AM Greg Sabino Mullane <htamfids@gmail.com> wrote:
> This is the correct interpretation. A regular refresh simply runs the query and replaces the old view, regardless of
thenumber of rows that have changed. A concurrent refresh runs the query and updates the rows in place, so it is very
sensitiveas to how many of those rows have changed. This also means that many concurrent refreshes can lead to table
bloat.And it will generate more WAL than a regular refresh. 
>
> My takeaway: use regular refresh when you can. Switch to concurrent if the number of changes is very small, or if
constantclient access to the view is very important. 

This makes sense to me. Many thanks.

Cheers,
Tobias