Re: [HACKERS] Dropping a partitioned table takes too long - Mailing list pgsql-hackers

From Amit Langote
Subject Re: [HACKERS] Dropping a partitioned table takes too long
Date
Msg-id 71359b9b-6a3d-df50-766c-0c5abc09e2bd@lab.ntt.co.jp
Whole thread Raw
In response to Re: [HACKERS] Dropping a partitioned table takes too long  (高增琦 <pgf00a@gmail.com>)
Responses Re: [HACKERS] Dropping a partitioned table takes too long  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi,

On 2017/04/25 20:07, 高增琦 wrote:
> 
> 2017-04-25 15:07 GMT+08:00 Amit Langote <Langote_Amit_f8@lab.ntt.co.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




pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtranslinks incorrectly
Next
From: Michael Paquier
Date:
Subject: Re: PG 10 release notes