David Rowley <dgrowle...@gmail.com> writes: > Looking at your changes to SlabFree(), I don't really think that > change is well aligned to the newly proposed policy. My understanding > of the rationale behind this policy is that large chunks get malloced > and will be slower anyway, so the elog(ERROR) is less overhead for > those. In SlabFree(), we're most likely not doing any free()s, so I > don't quite understand why you've added the elog rather than the > Assert for this case. The slab allocator *should* be very fast.
Yeah, slab.c hasn't any distinction between large and small chunks, so we have to just pick one policy or the other. I'd hoped to get away with the more robust runtime test on the basis that slab allocation is not used so much that this'd result in any noticeable performance change. SlabRealloc, at least, is not used *at all* per the code coverage tests, and if we're there at all we should be highly suspicious that something is wrong. However, I could be wrong about SlabFree, and if you're going to hold my feet to the fire then I'll change it rather than try to produce some performance evidence. regards, tom lane