Stephen Frost <sfrost@snowman.net> writes:
> This is likely to be naive, but perhaps it'll help others understand
> too. Would it be sensible to look at trying to fill a 2K request from
> the next-larger (4K-chunk) freelist before allocating a new chunk?
That doesn't sound like a very good idea --- in the worst case it could
lead to giving out 8K chunks to satisfy very small requests. I realize
that you're thinking of looking at only the next-larger freelist, but
that would not be enough to solve the problem, because the repalloc'd
chunk might've been enlarged more than 2X before it finally got returned
to the freelists. (I did not mention it before because it didn't seem
relevant, but the test case I was looking at actually does go through
2 rounds of doubling of the regexp_matches workspace before it returns
it to the freelists.) So to solve the problem that way you'd have to be
willing to use *any* larger chunk to satisfy a request, and that seems
to me to be way too inefficient storage-wise.
Also, if you're thinking of dividing an existing chunk into two
half-size chunks, that doesn't work because of the need for header space
for each chunk --- you'd end up with some chunks slightly smaller than
standard, which would add its own inefficiencies.
regards, tom lane