Re: unsupportable composite type partition keys
От | Amit Langote |
---|---|
Тема | Re: unsupportable composite type partition keys |
Дата | |
Msg-id | CA+HiwqH7HKEa+bUpF2pSWpRRZV6E0v5YxLWRW2gBQ=WYw8L5oQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: unsupportable composite type partition keys (Amit Langote <amitlangote09@gmail.com>) |
Ответы |
Re: unsupportable composite type partition keys
|
Список | pgsql-hackers |
On Tue, Dec 24, 2019 at 10:59 AM Amit Langote <amitlangote09@gmail.com> wrote: > Btw, does the memory leakage fix in this patch address any of the > pending concerns that were discussed on the "hyrax vs. > RelationBuildPartitionDesc" thread earlier this year[1]? > > [1] https://www.postgresql.org/message-id/flat/3800.1560366716%40sss.pgh.pa.us#092b6b4f6bf75d2f3f90ef6a3b3eab5b I thought about this a little and I think it *does* address the main complaint in the above thread. The main complaint as I understand is that receiving repeated invalidations due to partitions being concurrently added while a PartitionDirectory is holding a pointer to PartitionDesc causes many copies of PartitionDesc to pile up due to the parent table being rebuilt upon processing of each invalidation. Now because we don't build the PartitionDesc in the RelationClearRelation path, that can't happen. Although it still seems possible for the piling up to occur if it's RelationBuildPartitionDesc that is run repeatedly via RelationGetParttionDesc while partitions are being concurrently added, but I couldn't find anything in the partitioning code that does that. Thanks, Amit
В списке pgsql-hackers по дате отправления: