Re: patch: tsearch - some memory diet
От | Tom Lane |
---|---|
Тема | Re: patch: tsearch - some memory diet |
Дата | |
Msg-id | 13016.1283880654@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: patch: tsearch - some memory diet (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: patch: tsearch - some memory diet
|
Список | pgsql-hackers |
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: > A more general solution would be to have a new MemoryContext > implementation that does the same your patch does. Ie. instead of > tracking each allocation, just allocate a big chunk, and have palloc() > return the next n free bytes from it, like a stack. pfree() would > obviously not work, but wholesale MemoryContextDelete of the whole > memory context would. The trick with that is to not crash horribly if pfree or GetMemoryChunkSpace or GetMemoryChunkContext is applied to such a chunk. Perhaps we can live without that requirement, but it greatly limits the safe usage of such a context type. In the particular case here, the dictionary structures could probably safely use such a context type, but I'm not sure it's worth bothering if the long-term plan is to implement a precompiler. There would be no need for this after the precompiled representation is installed, because that'd just be one big hunk of memory anyway. regards, tom lane
В списке pgsql-hackers по дате отправления: