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(at)debis(dot)com (Jan Wieck) #