Re: [HACKERS] Dropping a partitioned table takes too long
От | Amit Langote |
---|---|
Тема | Re: [HACKERS] Dropping a partitioned table takes too long |
Дата | |
Msg-id | 71359b9b-6a3d-df50-766c-0c5abc09e2bd@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] Dropping a partitioned table takes too long (高增琦 <pgf00a@gmail.com>) |
Ответы |
Re: [HACKERS] Dropping a partitioned table takes too long
|
Список | 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 по дате отправления: