BUG #15851: Concurrent Refresh of Materialized views not preserving the order of the underlying query

On Thursday, June 13, 2019, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> > Materialized view refresh concurrently with unique index:
> > Sort order is not the same as that of the output of the underlying query
>
> I do not think this is a bug. A matview is basically a table, and
> tables don't guarantee to preserve row ordering.
>
> Possibly we need to clarify the docs around this point.
>
> A more aggressive approach would be to reject ORDER BY in the
> query defining a matview, but perhaps that's too in-your-face...
>
>
The notes section for refresh already mentions cluster and adding an
explicit order by; and they both seem like good points when working with
non-concurrent semantics. Probably should just add another sentence or two:

When operating in CONCURRENTLY mode the deltas that are calculated are
applied as a sequence of normal insert/update/delete. A subsequent CLUSTER
would need to be run on the materialized view if one wishes for the entire
table to be physically ordered again (though consider a lower fill-factor
for the materialized view to reduce the amount of work such a cluster would
need to accomplish).

David J.