On 5/9/25 16:17, Peter Geoghegan wrote:
> On Fri, May 9, 2025 at 8:58 AM Tomas Vondra <tomas@vondra.me> wrote:
>> I'm also not sure about the root cause, but while investigating it one
>> of the experiments I tried was tweaking the glibc malloc by setting
>>
>> export MALLOC_TOP_PAD_=$((64*1024*1024))
>>
>> which keeps a 64MB "buffer" in glibc, to reduce the amount of malloc
>> syscalls. And with that, the results change to this:
>
> You're sure that the problem is an increase in the number of
> malloc()s? If that's what this is, then it shouldn't be too hard to
> debug.
>
No, I'm not sure. I merely speculate based on the observation that
setting the environment variable makes the issue go away.
I've seen similar problems with btree before, as it allocates fairly
large chunks of memory for BTScanOpaque.
--
Tomas Vondra