From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | 高增琦 <pgf00a(at)gmail(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Dropping a partitioned table takes too long |
Date: | 2017-04-26 02:05:27 |
Message-ID: | 71359b9b-6a3d-df50-766c-0c5abc09e2bd@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2017/04/25 20:07, 高增琦 wrote:
>
> 2017-04-25 15:07 GMT+08:00 Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>:
>
>> $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.
>
> The attached patch try to replace 'heap_open' with 'LockRelationOid' when
> locking parent table.
> It improved dropping a table with 7000 partitions.
Your patch seems to be a much better solution to the problem, thanks.
Regards,
Amit
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-04-26 02:06:03 | Re: PG 10 release notes |
Previous Message | Michael Paquier | 2017-04-26 02:03:18 | Re: StandbyRecoverPreparedTransactions recovers subtrans links incorrectly |