Re: hyrax vs. RelationBuildPartitionDesc
От | Heikki Linnakangas |
---|---|
Тема | Re: hyrax vs. RelationBuildPartitionDesc |
Дата | |
Msg-id | 2efba7eb-7fab-59db-68bd-9a03e39588eb@iki.fi обсуждение исходный текст |
Ответ на | Re: hyrax vs. RelationBuildPartitionDesc (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: hyrax vs. RelationBuildPartitionDesc
Re: hyrax vs. RelationBuildPartitionDesc |
Список | pgsql-hackers |
On 15/03/2019 00:08, Tom Lane wrote: > What I'm thinking, therefore, is that 2455ab488 had the right idea but > didn't take it far enough. We should remove the temp-context logic it > added to RelationBuildPartitionDesc and instead put that one level up, > in RelationBuildDesc, where the same temp context can serve all of these > leak-prone sub-facilities. > > Possibly it'd make sense to conditionally compile this so that we only > do it in a CLOBBER_CACHE_ALWAYS build. I'm not very sure about that, > but arguably in a normal build the overhead of making and destroying > a context would outweigh the cost of the leaked memory. The main > argument I can think of for doing it all the time is that having memory > allocation work noticeably differently in CCA builds than normal ones > seems like a recipe for masking normal-mode bugs from the CCA animals. Having CLOBBER_CACHE_ALWAYS behave differently sounds horrible. We maintain a free list of AllocSetContexts nowadays, so creating a short-lived context should be pretty cheap. Or if it's still too expensive, we could create one short-lived context as a child of TopMemoryContext, and reuse that on every call, resetting it at the end of the function. - Heikki
В списке pgsql-hackers по дате отправления: