Re: Performance degradation of REFRESH MATERIALIZED VIEW
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
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-21T16:43:44Z
Lists: pgsql-hackers
Hi, On 2021-05-21 18:17:01 +0200, Tomas Vondra wrote: > OK, so here are the flamegraphs, for all three cases - current master, > 0c7d3bb99 (i.e. before heap_insert changes) and with the pinning patch > applied. I did this using the same test case as before (50M table), but with > -fno-omit-frame-pointer to get better profiles. It may add some overhead, > but hopefully that applies to all cases equally. > > The first 10 runs for each case look like this: > > old master patched > ---------------------- > 55045 74284 58246 > 53927 74283 57273 > 54090 74114 57336 > 54194 74059 57223 > 54189 74186 57287 > 54090 74113 57278 > 54095 74036 57176 > 53896 74215 57303 > 54101 74060 57524 > 54062 74021 57278 > ---------------------- > 54168 74137 57392 > 1.36x 1.05x > > which is mostly in line with previous findings (the master overhead is a bit > worse, possibly due to the frame pointers). > > Attached are the flame graphs for all three cases. The change in master is > pretty clearly visible, but I don't see any clear difference between old and > patched code :-( I'm pretty sure it's the additional WAL records? 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