Horton

Re: Performance degradation of REFRESH MATERIALIZED VIEW

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Michael Paquier <michael@paquier.xyz>, Tomas Vondra <tomas.vondra@enterprisedb.com>, Andres Freund <andres@anarazel.de>, Masahiko Sawada <sawada.mshk@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Pavan Deolasee <pavan.deolasee@gmail.com>, Anastasia Lubennikova <a.lubennikova@postgrespro.ru>, Jeff Janes <jeff.janes@gmail.com>, Paul Guo <guopa@vmware.com>
Date: 2021-05-13T02:47:31Z
Lists: pgsql-hackers 
On Tue, May 11, 2021 at 11:46 AM Andrew Dunstan <andrew@dunslane.net> wrote:
> > Yes, reverting has its place.  Moreover, threats of reversion have their
> > place.  People should definitely be working towards finding solutions to
> > the problems in their commits lest they be reverted.  However, freezing
> > *people* by saying that no fixes are acceptable other than reverts ...
> > is not good.
> >
> > So I agree with what Andres is saying downthread: let's apply the fix he
> > proposed (it's not even that invasive anyway), and investigate the
> > remaining 5% and see if we can find a solution.  If by the end of the
> > beta process we can definitely find no solution to the problem, we can
> > revert the whole lot then.
> >
>
>
> I agree with all of this. Right now I'm only concerned if there isn't
> work apparently being done on some issue.

+1. While reverting a patch is always on the table, it must be the
option of last resort. I don't have any specific reason to believe
that that's the point we're at just yet.

-- 
Peter Geoghegan

Commits

  1. Fix pg_visibility regression failure with CLOBBER_CACHE_ALWAYS

  2. Revert most of 39b66a91bd

  3. Fix COPY FREEZE with CLOBBER_CACHE_ALWAYS