Re: copy.c allocation constant

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: copy.c allocation constant
Date: 2018-01-24 17:27:48
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Wed, Jan 24, 2018 at 06:25:01PM +0100, Tomas Vondra wrote:
> >
> I think there there are two things to consider - aset.c and glibc.
> In AllocSet this is handled as over-sized chunk, that is chunk greater
> than ALLOC_CHUNK_LIMIT (which ends up being 8kB). Which means it's
> allocated as a separate block, and does not go through the freelists. So
> the size does not follow the usual "power of 2" pattern and is only
> maxalign-ed, and then freed immediately on pfree.
> So for AllocSet we're fine, and this should not result in any memory
> inefficiency, assuming there are not many such requests (which would
> result in many malloc/free calls, which may be somewhat expensive).
> At the glibc level ... I'm not so sure. AFAIK glibc uses an allocator
> with similar ideas (freelists, ...) so hopefully it's fine too.
> And then there are the systems without glibc, or with other libc
> implementations. No idea about those.

Thanks for the analysis.

Bruce Momjian <bruce(at)momjian(dot)us>

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2018-01-24 17:32:27 Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump
Previous Message Tomas Vondra 2018-01-24 17:25:01 Re: copy.c allocation constant