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 по дате отправления:

Предыдущее
От: MikalaiKeida@ibagroup.eu
Дата:
Сообщение: RE: Timeout parameters
Следующее
От: "Matsumura, Ryo"
Дата:
Сообщение: RE: Is PREPARE of ecpglib thread safe?