Re: Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c?
Date
Msg-id 8510.1303835300@sss.pgh.pa.us
Whole thread Raw
In response to Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c?  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Merlin Moncure <mmoncure@gmail.com> writes:
> I was poking around in the allocator code out of curiosity after
> reading the thread 'Improving the memory allocator', and noticed the
> following in spell.c:

> #define COMPACT_ALLOC_CHUNK 8192        /* must be > aset.c's allocChunkLimit */

> In aset.c, we have,

> #define ALLOC_MINBITS           3       /* smallest chunk size is 8 bytes */
> #define ALLOCSET_NUM_FREELISTS  11
> #define ALLOC_CHUNK_LIMIT       (1 << (ALLOCSET_NUM_FREELISTS-1+ALLOC_MINBITS))

> 1 << 13 gives 8192 if my math is correct.

> Note the comment, 'must be > aset.c's allocChunkLimit'.  Is the
> comment wrong or the assumption wrong?

Hmm ... the idea behind that comment is evidently that it's best if the
blocks allocated by this code form independent malloc blocks in aset.c;
but right offhand I can't see why that'd be important.  It's obviously
not functionally necessary, since the code works as-is, and I don't
immediately see a reason to think that it'd be more efficient.  If
anything it might be best the way it is, with the allocation
corresponding to the largest allowable small-chunk size.

I'm thinking the comment is just brain fade ... which is annoying
because I have a feeling it's my own comment :-( ... but I'm darned
if I can reconstruct the reasoning for it now.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: maximum digits for NUMERIC
Next
From: Tom Lane
Date:
Subject: Re: Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c?