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: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>
Cc: 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-04-26T13:31:02Z
Lists: pgsql-hackers 
Hi,

I took a look at this today, as I committed 39b66a91b back in January. I 
can reproduce the issue, with just 1M rows the before/after timings are 
roughly 480ms and 620ms on my hardware.

Unfortunately, the v3 patch does not really fix the issue for me. The 
timing with it applied is ~610ms so the improvement is only minimal.

I'm not sure what to do about this :-( I don't have any ideas about how 
to eliminate this overhead, so the only option I see is reverting the 
changes in heap_insert. Unfortunately, that'd mean inserts into TOAST 
tables won't be frozen ...


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