Re: Performance degradation of REFRESH MATERIALIZED VIEW

On 5/11/21 2:23 PM, Alvaro Herrera wrote:
> On 2021-May-11, Michael Paquier wrote:
>
>> Hmm. Is that really something we should do after feature freeze? A
>> 25% degradation for matview refresh may be a problem for a lot of
>> users and could be an upgrade stopper. Another thing we could do is
>> also to revert 7db0cd2 and 39b66a9 from the v14 tree, and work on a
>> proper solution for this performance problem for matviews for 15~.
>>
>> Thoughts?
> My main thought while reading this thread is about the rules of feature
> freeze. I mean, we are indeed in feature freeze, so no new features
> should be added. But that doesn't mean we are in code freeze. For the
> period starting now and until RC (which is a couple of months away
> still) we should focus on ensuring that the features we do have are in
> as good a shape as possible. If that means adding more code to fix
> problems/bugs/performance problems in the existing code, so be it.
> I mean, reverting is not the only tool we have.
>
> Yes, reverting has its place. Moreover, threats of reversion have their
> place. People should definitely be working towards finding solutions to
> the problems in their commits lest they be reverted. However, freezing
> *people* by saying that no fixes are acceptable other than reverts ...
> is not good.
>
> So I agree with what Andres is saying downthread: let's apply the fix he
> proposed (it's not even that invasive anyway), and investigate the
> remaining 5% and see if we can find a solution. If by the end of the
> beta process we can definitely find no solution to the problem, we can
> revert the whole lot then.
>

I agree with all of this. Right now I'm only concerned if there isn't
work apparently being done on some issue.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com