Re: GiST memory allocation

Neil Conway <neilc(at)samurai(dot)com> 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'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.

> I can't really think of a better solution than a static memory context.
> I don't think the reentrency will be a problem right now, but if it
> becomes a problem in the future we can solve it via some book-keeping
> (e.g. on entry to GiST bump a counter, when the counter == 0 and we're
> exiting a GiST API then reset the memory context).

And then you have created an error-recovery cleanup issue. I'm really
going to have to say NO, don't do that. In my professional opinion this
is a bad decision; especially so when the only real reason for doing it
at all is code cleanliness. The cleanup is a bit marginal in the first
place, and it is definitely not worth the price of turning re-entrant
code into non-re-entrant code, even if you can't yet foresee the day
when that will bite you.

regards, tom lane