Re: patch: tsearch - some memory diet - Mailing list pgsql-hackers

From Tom Lane
Subject Re: patch: tsearch - some memory diet
Date
Msg-id 13016.1283880654@sss.pgh.pa.us
Whole thread Raw
In response to Re: patch: tsearch - some memory diet  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: patch: tsearch - some memory diet
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: git: uh-oh
Next
From: Markus Wanner
Date:
Subject: Re: Synchronization levels in SR