* Tom Lane ([EMAIL PROTECTED]) 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
signature.asc
Description: Digital signature
