Horton

Re: Performance degradation of REFRESH MATERIALIZED VIEW

Tomas Vondra <tomas.vondra@enterprisedb.com>

View thread View on postgr.es
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-05-24T22:30:13Z
Lists: pgsql-hackers 
On 5/24/21 8:21 PM, Andres Freund wrote:
> Hi,
> 
> On 2021-05-24 12:37:18 +0200, Tomas Vondra wrote:
>> Another option might be changes in the binary layout - 5% change is well
>> within the range that could be attributed to this, but it feels very
>> hand-wavy and more like an excuse than real analysis.
> 
> I don't think 5% is likely to be explained by binary layout unless you
> look for an explicitly adverse layout.
> 

Yeah, true. But I'm out of ideas what might be causing the regression
and how to fix it :-(

> 
>> Hmmm, thanks for reminding us that patch. Why did we reject that approach in
>> favor of the current one?
> 
> Don't know about others, but I think it's way too fragile.
> 

Is it really that fragile? Any particular risks you have in mind? Maybe
we could protect against that somehow ... Anyway, that change would
certainly be for PG15.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Fix pg_visibility regression failure with CLOBBER_CACHE_ALWAYS

  2. Revert most of 39b66a91bd

  3. Fix COPY FREEZE with CLOBBER_CACHE_ALWAYS