Re: Add tracking of backend memory allocated to pg_stat_activity
От | Stephen Frost |
---|---|
Тема | Re: Add tracking of backend memory allocated to pg_stat_activity |
Дата | |
Msg-id | 20220909164004.GI26002@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: Add tracking of backend memory allocated to pg_stat_activity (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Список | pgsql-hackers |
Greetings, * Kyotaro Horiguchi (horikyota.ntt@gmail.com) wrote: > At Tue, 06 Sep 2022 17:10:49 -0400, Reid Thompson <reid.thompson@crunchydata.com> wrote in > > I'm open to guidance on testing for performance degradation. I did > > note some basic pgbench comparison numbers in the thread regarding > > limiting backend memory allocations. > > Yeah.. That sounds good.. > > (I have a patch that is stuck at benchmarking on slight possible > degradation caused by a branch (or indirect call) on a hot path > similary to this one. The test showed fluctuation that is not clearly > distinguishable between noise and degradation by running the target > functions in a busy loop..) Just to be clear- this path is (hopefully) not *super* hot as we're only tracking actual allocations (that is- malloc() calls), this isn't changing anything for palloc() calls that aren't also needing to do a malloc(), and we already try to reduce the amount of malloc() calls we're doing by allocating more and more each time we run out in a given context. While I'm generally supportive of doing some benchmarking around this, I don't think the bar is as high as it would be if we were actually changing the cost of routine palloc() or such calls. Thanks, Stephen
Вложения
В списке pgsql-hackers по дате отправления: