Re: Performance degradation of REFRESH MATERIALIZED VIEW
Tomas Vondra <tomas.vondra@enterprisedb.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Andres Freund <andres@anarazel.de>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>,
Michael Paquier <michael@paquier.xyz>,
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-06-02T23:02:17Z
Lists: pgsql-hackers
OK, As mentioned in the previous message, I've reverted most of 39b66a91bd. It took a bit longer to test, because the revert patch I shared a couple days ago was actually incorrect/buggy in one place. I'm not entirely happy about the end result (as it does not really help with TOAST tables), so hopefully we'll be able to do something about that soon. I'm not sure what, though - we've spent quite a bit of time trying to address the regression, and I don't envision some major breakthrough. As for the regression example, I think in practice the impact would be much lower, because the queries are likely much more complex (not just a seqscan from a table), so the query execution will be a much bigger part of execution time. I do think the optimization would be a win in most cases where freezing is desirable. From this POV the problem is rather that REFRESH MV does not allow not freezing the result, so it has to pay the price always. So perhaps the way forward is to add "NO FREEZE" option to REFRESH MV, or something like that. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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