Re: Performance degradation of REFRESH MATERIALIZED VIEW

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Performance degradation of REFRESH MATERIALIZED VIEW
Дата
Msg-id 20210521164344.ortxzvuw2p5lvf4w@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Performance degradation of REFRESH MATERIALIZED VIEW  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: Performance degradation of REFRESH MATERIALIZED VIEW  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Performance degradation of REFRESH MATERIALIZED VIEW
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Race condition in recovery?