* Tom Lane (tgl@sss.pgh.pa.us) wrote:
[...]
> 3. When regexp_matches is done with the current call, it politely
> releases the chunk, and AllocSetFree sticks it into the freelist for
> 4K chunks.
>
> 4. The next call of regexp_matches asks for a 2K chunk. There's nothing
> in the 2K chunk freelist, so AllocSetAlloc allocates a new chunk from
> the end of the context's current memory block.
>
> Lather, rinse, repeat --- each cycle adds another entry to the 4K-chunk
> freelist, which we'll never use.
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?
Could it, essentially, "downgrade" the 4K chunk into 2 2K chunks when
that's what is being asked for (and the 2K freelist is empty, and the 4K
freelist isn't, etc)?
The realloc-in-place seems like a good idea in general, but this test
case does need to be handled in some clean way. Perhaps allowing a
"downgrade" path along with the "upgrade" path would work well.
(If that's what you were suggesting already, then sorry for the noise)
Thanks,
Stephen