From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tv(at)fuzzy(dot)cz>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SlabCheck leaks memory into TopMemoryContext |
Date: | 2020-01-17 14:40:04 |
Message-ID: | 20200117144004.k3rjrypctn55mqnh@development |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 16, 2020 at 01:41:39PM -0500, Tom Lane wrote:
>Andres Freund <andres(at)anarazel(dot)de> writes:
>> On 2020-01-16 18:01:53 +0100, Tomas Vondra wrote:
>>> and it's only really used in debug builds anyway. So I'm not all that
>>> woried about this wasting a couple extra kB of memory.
>
>> IDK, making memory usage look different makes optimizing it harder. Not
>> a hard rule, obviously, but ...
>
>Well, if you're that excited about it, make a patch so we can see
>how ugly it ends up being.
>
I think the question is how much memory would using globals actually
save, compared to including the bitmap in SlabContext.
The bitmap size depends on block/chunk size - I don't know what
parameters Andres uses for the additional contexts, but for the two
places already using Slab we have 8kB blocks with 80B and 240B chunks,
so ~102 and ~34 chunks in a block. So it's not a huge amount, and we
could easily reduce this to 1/8 by switching to a proper bitmap.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2020-01-17 15:48:53 | Re: Expose lock group leader pid in pg_stat_activity |
Previous Message | Stephen Frost | 2020-01-17 14:37:17 | Re: Complete data erasure |