From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | reid(dot)thompson(at)crunchydata(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Add tracking of backend memory allocated to pg_stat_activity |
Date: | 2022-09-09 16:40:04 |
Message-ID: | 20220909164004.GI26002@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* Kyotaro Horiguchi (horikyota(dot)ntt(at)gmail(dot)com) wrote:
> At Tue, 06 Sep 2022 17:10:49 -0400, Reid Thompson <reid(dot)thompson(at)crunchydata(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2022-09-09 16:46:25 | Re: ICU for global collation |
Previous Message | Alvaro Herrera | 2022-09-09 16:37:07 | Re: [PATCH] Fix alter subscription concurrency errors |