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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: sai(dot)dulla(at)berkeley(dot)edu, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15851: Concurrent Refresh of Materialized views not preserving the order of the underlying query
Date: 2019-06-17 16:48:39
Message-ID: 20190617164839.ypjeuytjvjp7ezo5@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

On 2019-06-13 20:28:54 -0400, Tom Lane wrote:
> A more aggressive approach would be to reject ORDER BY in the
> query defining a matview, but perhaps that's too in-your-face...

That'd probably be over the top - ISTM it can make plenty of sense to
"pre order" a matview, especially if you're going to create several
indexes.

Greetings,

Andres Freund

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2019-06-17 16:50:22 Re: BUG #15844: MIPS: remove .set mips2 in s_lock.h to fix r6 build
Previous Message Andres Freund 2019-06-17 16:32:07 Re: BUG #15844: MIPS: remove .set mips2 in s_lock.h to fix r6 build