Re: Misc. consequences of backend memory management changes

On Wed, 28 Jun 2000, Tom Lane wrote:

> I'm about halfway done with revising backend memory management per

haha, I just prepare first query cache snapshot and what I see,
Tom already rewrite aset/mcxt and my routines are out-of-date.
But it is right, with your changes it will query cache better :-)

Well, I a little surprise that you remove all aset definiton from
header files to aset.c. If anyone will write new context type, he
can't uses some already exist definition.

IMHO not will bad if all context types (now exists aset type only)
will more transparently and will own header files and at first sight will
visible what is common memory routines and what specific.

I believe that current memory managemet changes create more _modular_
mem code.

About context tree --- what will happen if in PG will exist some context
that not will in context tree? Yes, it is curios question...explication:
I have in the query cache contexts (for each plan) that are persisten (in
shmem) across connection (and across TopMemoryContext live-time). How
integrate this context to the contect tree? Or skip for this specific
variant context type independent MemoryContextCreate and init this common
part itself? - (I vote for this)

New pfree(), repalloc() are nice.

Plan you some changes in SPI? I have new code for SPI save plan
(per-context and via query cache).

And last question, is current mcxt.c API final? I want port my query cache
to compatible with current interface.

Karel