Re: Performance degradation of REFRESH MATERIALIZED VIEW

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andrew Dunstan <andrew@dunslane.net>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Tomas Vondra <tomas.vondra@enterprisedb.com>, 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:16:39Z
Lists: pgsql-hackers
Hi,

On 2021-05-13 11:12:43 +0900, Michael Paquier wrote:
> If that's the consensus reached, that's fine by me as long as we don't
> keep a 25% performance regression.  Now, looking at the patch
> proposed, I have to admit that this looks like some redesign of an
> existing feature, so that stresses me a bit in a period when we are
> aiming at making things stable, because this has a risk of making a
> part of the code more unstable.

You're referencing tracking the vm page in the bulk insert state? I
don't see how you get a less invasive fix that's not architecturally
worse than this. If that's over your level of comfort, I don't see an
alternative but to revert. But I also don't think it's particularly
invasive?

Greetings,

Andres Freund



Commits

  1. Fix pg_visibility regression failure with CLOBBER_CACHE_ALWAYS

  2. Revert most of 39b66a91bd

  3. Fix COPY FREEZE with CLOBBER_CACHE_ALWAYS