Re: Dropping a partitioned table takes too long

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

In response to

Responses

Browse pgsql-hackers by date

  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