Andrew Gierth wrote:
> A quick scan of the code suggests that the worst case is when blocks are
> being freed in FIFO order, which seems quite plausible in this case, and
> the performance is potentially O(N^2).
>
> So I think this is primarily an artifact of doing so much retail
> palloc/pfree in a single memory context.
As I recall, this is the main reason Andres stuck the slab cache in
reorderbuffer. Maybe it'd be worthwhile to implement a different
MemoryContext tailored to this use case, and remove the slab cache
stuff.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services