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

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 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@debis.com (Jan Wieck) #