Re: Performance degradation of REFRESH MATERIALIZED VIEW

On 5/11/21 7:25 PM, Andres Freund wrote:
> 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?
>

Probably not, I was just a little bit confused what exactly is going on,
unsure what to do about it. But if RMV freezes the rows, that probably
explains it and your patch is the way to go.

>
>> 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...
>

OK. I'm mostly afk at the moment, I'll do that once I get back home,
sometime over the weekend / maybe early next week.

regards

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