Stephen Frost <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq