Tom Lane wrote:
> wieck@debis.com (Jan Wieck) writes:
> > Then again, copyObject/freeObject must be fixed WRT
> > leakage/multiref anyway.
>
> Not if we decide to get rid of freeObject, instead.
>
> I think that a little work would have to be done to support efficient
> use of large numbers of contexts, but it's certainly doable. This
> path seems more attractive than trying to make the world safe for
> freeObject of arbitrary node trees.
Yes, little work to build the framework. All alloc/realloc/free functions for a particular
context are just function-pointers inside the context structure itself. So ther'll be no additional call overhead
when dealing with large numbers of contexts.
OTOH, this new per-object-context stuff could hand down some lifetime flag, let's say MCXT_UNTIL_STATEMENT,
MCXT_UTIL_XEND and MCXT_UNTIL_INFINITY to start from. The memory context creation/destruction routines could
managesome global lists of contexts, that automatically get destroyed on AtXactCommitMemory and so
on,making such a kind of per- object memory context a fire'n'forget missile (Uh - played F15 too
excessively :-). It should still be destroyed explicitly if not needed anymore, but if allocated with the
correctlifetime, wouldn't hurt that much if forgotten.
More work to get all the existing places in the backend making use of this functionality where applicable.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #