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'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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings