Re: Dropping a partitioned table takes too long

The attached patch try to replace 'heap_open' with 'LockRelationOid' when
locking parent table.
It improved dropping a table with 7000 partitions.

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.
>
> Thoughts?
>
> Adding this to the open items list.
>
> Thanks,
> Amit
>
> PS: this was actually mentioned by Ragnar Ouchterlony who reported some
> bugs back in declarative partitioning in January [1]
>
> [1]
> https://www.postgresql.org/message-id/17d89e08-874b-c1b1-
> aa46-12d5afb26235%40agama.tv
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>

--
GaoZengqi
pgf00a(at)gmail(dot)com
zengqigao(at)gmail(dot)com