Re: Performance degradation of REFRESH MATERIALIZED VIEW

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Paul Guo <guopa(at)vmware(dot)com>
Subject: Re: Performance degradation of REFRESH MATERIALIZED VIEW
Date: 2021-05-11 17:25:00
Message-ID: 20210511172500.adztpgg4vbnjdeca@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2021-05-11 16:07:44 +0200, Tomas Vondra wrote:
> On 5/11/21 11:04 AM, Masahiko Sawada wrote:
> > I think the changes for heap_multi_insert() are fine so we can revert
> > only heap_insert() part if we revert something from the v14 tree,
> > although we will end up not inserting frozen tuples into toast tables.
> >
>
> I'd be somewhat unhappy about reverting just this bit, because it'd mean
> that we freeze rows in the main table but not rows in the TOAST tables (that
> was kinda why we concluded we need the heap_insert part too).

Is there a reason not to apply a polished version of my proposal? And
then to look at the remaining difference?

> I'm still a bit puzzled where does the extra overhead (in cases when freeze
> is not requested) come from, TBH. Intuitively, I'd hope there's a way to
> eliminate that entirely, and only pay the cost when requested (with the
> expectation that it's cheaper than freezing it that later).

I'd like to see a profile comparison between those two cases. Best with
both profiles done in master, just once with the freeze path disabled...

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2021-05-11 17:30:14 Re: PG 14 release notes, first draft
Previous Message Andres Freund 2021-05-11 17:22:11 Re: Why do we have perl and sed versions of Gen_dummy_probes?