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

Karel wrote:

> > Why is memory context per plan bad ?
>
>  One context is more simple.
   I  don't  see  much complexity difference between one context   per plan vs. one context for  all.  At  least  if  we  do  it   transparently inside of SPI_saveplan() and SPI_freeplan().

>  We talking about a *cache*. If exist interface for this cache and
>  all operations are with copy/freeObject it not has restriction.
>
>  For how action it will restriction?
   No restrictions I can see.
   But I think one context per plan is still better, since first   there is no leakage/multiref  problem.  Second,  there  is  a   performance   difference   between   explicitly   pfree()'ing   hundreds of small allocations (in freeObject() traverse), and   just  destroying  a  context.  The  changes  I  made  to  the   MemoryContextAlloc stuff for v6.5 (IIRC), using bigger blocks   incl.  padding/reuse  for small allocations, caused a speedup   of 5+% for the entire regression test. This was only  because   it  uses lesser real calls to malloc()/free() and the context   destruction does not need to process  a  huge  list  of  all,   however small allocations anymore.  It simply throws away all   blocks now.
   This  time,  we  talk  about  a   more   complex,   recursive   freeObject(), switch()'ing for every node type into separate,   per object  type  specific  functions,  pfree()'ing  all  the   little  chunks.   So  there  is  at  least  a  difference  in   first/second-level RAM cache rows required. And if  that  can   simply  be  avoided by using one context per plan, I vote for   1by1.
   Then  again,  copyObject/freeObject   must   be   fixed   WRT   leakage/multiref anyway.


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) #