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
