On 2017/04/25 20:55, Ashutosh Bapat wrote:
> On Tue, Apr 25, 2017 at 12:37 PM, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>> $SUBJECT, if the table has, say, 2000 partitions.
>>
>> The main reason seems to be that RelationBuildPartitionDesc() will be
>> called that many times within the same transaction, which perhaps we
>> cannot do much about right away. But one thing we could do is to reduce
>> the impact of memory allocations it does. They are currently leaked into
>> the caller's context, which may not be reset immediately (such as
>> PortalHeapMemory). Instead of doing it in the caller's context, use a
>> temporary context that is deleted before returning. Attached is a patch
>> for that. On my local development VM, `drop table
>> table_with_2000_partitions` finished in 27 seconds with the patch instead
>> of more than 20 minutes that it currently takes.
>>
>> Thoughts?
>>
> I am not able to undestand why does changing memory context cause so
> much difference in execution time?
>
> The way this patch uses the memory context in this patch, it's
> possible that in future we will allocate something in temporary
> context and then refer it from a longer context. Instead, may be we
> should free things specially or change memory context only when
> allocating those things.
Actually, I am withdrawing this patch for time being, because a much
direct and better solution has been offered upthread by GaoZengqi.
Anyway, temporary context added by my patch would not contain any objects
that will be accessed outside of RelationBuildPartitionDesc(). Remember
that the content that we put into the longer-lived rd_partdesc uses the
memory allocated in rd_pdcxt, not the temporary context that I proposed.
Thanks,
Amit
