Re: copy.c allocation constant

On 01/24/2018 04:14 AM, Bruce Momjian wrote:
> On Tue, Nov 28, 2017 at 11:51:28AM -0500, Andrew Dunstan wrote:
>>
>>
>> While reading copy.c I noticed this line:
>>
>>
>> #define RAW_BUF_SIZE 65536        /* we palloc RAW_BUF_SIZE+1 bytes */
>>
>>
>> Doesn't that seem rather odd? If we're adding 1 wouldn't it be better as
>> 65535 so we palloc a power of 2?
>>
>>
>> I have no idea if this affects performance, but it did strike me
>> as strange.
>
> Coming in late here, but it does seem very odd.
>

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.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services