Re: Performance degradation of REFRESH MATERIALIZED VIEW
От | Andres Freund |
---|---|
Тема | Re: Performance degradation of REFRESH MATERIALIZED VIEW |
Дата | |
Msg-id | 20210426192746.hkdqpvokpxbvdif6@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Performance degradation of REFRESH MATERIALIZED VIEW (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: Performance degradation of REFRESH MATERIALIZED VIEW
|
Список | pgsql-hackers |
Hi, On 2021-04-26 15:31:02 +0200, Tomas Vondra wrote: > I'm not sure what to do about this :-( I don't have any ideas about how to > eliminate this overhead, so the only option I see is reverting the changes > in heap_insert. Unfortunately, that'd mean inserts into TOAST tables won't > be frozen ... ISTM that the fundamental issue here is not that we acquire pins that we shouldn't, but that we do so at a much higher frequency than needed. It's probably too invasive for 14, but I think it might be worth exploring passing down a BulkInsertState in nodeModifyTable.c's table_tuple_insert() iff the input will be more than one row. And then add the vm buffer of the target page to BulkInsertState, so that hio.c can avoid re-pinning the buffer. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: