Tom Lane wrote:
I don't believe memory context creation is very much worse than a malloc
(and it's certainly not that much worse than a context reset).
If you can't buy back the time spent by avoiding some retail pfrees, then
this whole exercise becomes very questionable anyway.
Hmm, okay -- I'll j
Neil Conway <[EMAIL PROTECTED]> writes:
> One alternative is to create memory contexts for each insertion /
> creation / deletion operation, but that is pretty ugly, and probably
> inefficient for insertion/deletion.
I don't believe memory context creation is very much worse than a malloc
(and it'
On Tue, 2004-11-02 at 02:20, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > (the observation here is that 99% of the allocations done by
> > gist.c are for internal use only -- we rarely allocate anything that
> > needs to live longer than the current GiST API call).
>
> You sure
Neil Conway <[EMAIL PROTECTED]> writes:
> AFAICS, GiST doesn't take any advantage of the palloc() infrastructure
> beyond treating palloc() as a better malloc().
This is pretty much true of all the index AMs, I think. I looked
briefly at using a short-term memory context in the btree code, but
g
Memory allocation in access/gist/gist.c is pretty heinous, IMHO. There
are retail pallocs and pfrees all over the place, and the requirements
for which allocations need to be released and by whom is pretty messy.
AFAICS, GiST doesn't take any advantage of the palloc() infrastructure
beyond trea
