$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
