* 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