On Wed, Jul 13, 2016 at 11:36 AM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
>> 0011c0091e886b874e485a46ff2c94222ffbf550. This allowed tuplesort.c to
>> blow away the free list via a new call to MemoryContextReset(). This
>> didn't even remove *any* pfree() operations in the affected codepath,
>> but was still quite effective.
>>
>> I'm not sure that that's comparable, but it may be an interesting case
>> that others are not aware of.
>>
>
> I'm not very familiar with the reorderbuffer.c, but my understanding is that
> it's an object with potentially very long lifetime, doing a lot of
> interleaved palloc/pfree (or accessing the slab cache). The lifetime of
> tuplesort is much shorter with clear boundaries, and probably does not need
> palloc/pfree interleaved that much.
Actually, the lifetime of a non-final merge step could be tens of
seconds or more, and there are continual palloc() and pfree() calls at
the tuple level, which leads to this fragmentation. (Note that this
does apply to final on-the-fly merges, which were made to use batch
memory by that same commit.)
--
Peter Geoghegan
