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
-
Fix pg_visibility regression failure with CLOBBER_CACHE_ALWAYS
- d1f0aa769691 14.0 landed
-
Revert most of 39b66a91bd
- 8e03eb92e9ad 14.0 landed
-
Fix COPY FREEZE with CLOBBER_CACHE_ALWAYS
- 39b66a91bdeb 14.0 cited