From: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)com>, pgsql-docs(at)postgresql(dot)org |
Subject: | Re: ORDER BY in materialized view example? |
Date: | 2021-11-23 18:11:08 |
Message-ID: | 0db5b15e-ce75-f572-2686-b6209084c8e6@postgresql.org |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
On 11/23/21 12:44 PM, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)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.
+1
> 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.
+1. I think I got bit by this in the real world years back. The above
comment is pretty clear.
Thanks,
Jonathan
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2021-11-24 00:50:13 | Re: max_slot_wal_keep_size unit is not specified |
Previous Message | Tom Lane | 2021-11-23 17:44:56 | Re: ORDER BY in materialized view example? |