Re: [HACKERS] Cache query (PREPARE/EXECUTE)

Tom Lane wrote:

> wieck(at)debis(dot)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 manage some 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
correct lifetime, 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(at)debis(dot)com (Jan Wieck) #