MIME-Version: 1.0
From: Tobias McNulty <tobias@caktusgroup.com>
Date: Sat, 22 Feb 2025 20:57:52 -0500
Message-ID: <CAMGFDKTW+SgLgdqRNa4cx9x1rFbA=2_8SE51r30A8o+9N2ikpA@mail.gmail.com>
Subject: documentation question regarding REFRESH MATERIALIZED VIEW CONCURRENTLY
To: pgsql-general@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAMGFDKTW%2BSgLgdqRNa4cx9x1rFbA%3D2_8SE51r30A8o%2B9N2ikpA%40mail.gmail.com>
Precedence: bulk

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