Re: memory leak in trigger handling (since PG12)
От | Tomas Vondra |
---|---|
Тема | Re: memory leak in trigger handling (since PG12) |
Дата | |
Msg-id | 0376ae2d-570e-8837-9e93-8ada1deb2cee@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: memory leak in trigger handling (since PG12) (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On 5/24/23 22:19, Andres Freund wrote: > > ... > > Hm - stepping back a bit, why are we doing the work in ExecGetAllUpdatedCols() > over and over? Unless I am missing something, the result doesn't change > across rows. And it doesn't look that cheap to compute, leaving aside the > allocation that bms_union() does. > > It's visible in profiles, not as a top entry, but still. > > Perhaps the easiest to backpatch fix is to just avoid recomputing the value? > But perhaps it'd be just as problmeatic, because callers might modify > ExecGetAllUpdatedCols()'s return value in place... > Yes, I think that's a perfectly valid point - I was actually wondering about that too, but I was focused on fixing this in backbranches so I left this as a future optimization (assuming it can be cached). regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: