Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mpZqq-0005iK-R8 for pgsql-docs@arkaria.postgresql.org; Tue, 23 Nov 2021 17:45:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mpZqp-0004Ph-11 for pgsql-docs@arkaria.postgresql.org; Tue, 23 Nov 2021 17:45:03 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mpZqo-0004PW-Ph for pgsql-docs@lists.postgresql.org; Tue, 23 Nov 2021 17:45:02 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mpZqm-0004sE-DE for pgsql-docs@postgresql.org; Tue, 23 Nov 2021 17:45:02 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 1ANHiuRm038997; Tue, 23 Nov 2021 12:44:57 -0500 From: Tom Lane To: Peter Eisentraut cc: Maciek Sakrejda , pgsql-docs@postgresql.org Subject: Re: ORDER BY in materialized view example? In-reply-to: <1e9f99f9-9cdb-4bc3-85d9-c017fbc54566@enterprisedb.com> References: <1e9f99f9-9cdb-4bc3-85d9-c017fbc54566@enterprisedb.com> Comments: In-reply-to Peter Eisentraut message dated "Tue, 23 Nov 2021 17:06:32 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <38995.1637689496.1@sss.pgh.pa.us> Date: Tue, 23 Nov 2021 12:44:56 -0500 Message-ID: <38996.1637689496@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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 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