Re: ORDER BY in materialized view example?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Maciek Sakrejda <m.sakrejda@gmail.com>, pgsql-docs@postgresql.org
Date: 2021-11-23T17:44:56Z
Lists: pgsql-docs
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 23.11.21 07:18, Maciek Sakrejda wrote:
>> An example in the materialized view documentation [1] includes an ORDER
>> BY clause without a clear reason. Does it help build the index more
>> efficiently? I suppose it's also sort of like a CLUSTER?
> I agree the ORDER BY is not relevant to the example. There might be
> some implementation-dependent advantage to ordering a materialized view,
> but if there is, it isn't explained in the example.
Yeah. It would result in the initial contents of the matview being
ordered, but I'm sure we don't wish to guarantee that REFRESH would
preserve that. I'm on board with just removing the ORDER BY from
that example.
There is also this rather opaque "note" in the REFRESH MATERIALIZED VIEW
man page:
While the default index for future CLUSTER operations is retained,
REFRESH MATERIALIZED VIEW does not order the generated rows based on
this property. If you want the data to be ordered upon generation, you
must use an ORDER BY clause in the backing query.
I'd rather say something like
If there is an ORDER BY clause in the matview's defining query,
the original contents of the matview will be ordered that way;
but REFRESH MATERIALIZED VIEW does not guarantee to preserve
that ordering.
regards, tom lane
Commits
-
Doc: improve documentation about ORDER BY in matviews.
- ce43b3dc52c9 14.2 landed
- a7359913a1c2 13.6 landed
- 514f0ae4f40f 10.20 landed
- 3f43dcc1c686 11.15 landed
- 2f908e1a3b9c 12.10 landed
- 4f33af23e7e3 15.0 landed