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...@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. > > 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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > > -- GaoZengqi pgf...@gmail.com zengqi...@gmail.com
0001-Don-t-building-a-relcache-entry-since-we-don-t-need-.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
