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?
But it seems like the ORDER BY should either be explained or dropped: as
is, this gives the impressio
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?
But it seems like the ORDER BY should either be explain
Peter Eisentraut 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
On 11/23/21 12:44 PM, Tom Lane wrote:
Peter Eisentraut 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 C
Thanks for the feedback. I only had passing familiarity with materialized
views and I didn't even realize the order would not be preserved. All the
more reason to drop that.
I'm attaching two patches: the first drops the original ORDER BY I e-mailed
about, and the second applies Tom's change to th
Maciek Sakrejda writes:
> I'm attaching two patches: the first drops the original ORDER BY I e-mailed
> about, and the second applies Tom's change to the man page note (verbatim,
> though with "materialized view" since the "matview" shorthand doesn't seem
> to be used in the docs, and with markup)
