Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> writes:
> 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 left AllocSetContext in memnodes.h temporarily, but I think in the
long run it should only be defined inside aset.c. Anyone else have
an opinion on that?
> About context tree --- what will happen if in PG will exist some context
> that not will in context tree?
You can certainly have top-level contexts that aren't children of
anything. There's no real functional distinction between a context
created like that and one that is a child of TopMemoryContext, because
we never reset/delete children of TopMemoryContext anyway. I was
careful to make all the other contexts descendants of TopMemoryContext
because I wanted to be able to call MemoryContextStats(TopMemoryContext)
to get a picture of all the memory usage. Other than that
consideration, CacheMemoryContext, ErrorContext, and so forth could
perfectly well have been top-level contexts with no parent.
A context representing shared memory probably should be a top-level
context, though. That would make sense if you think of TopMemoryContext
as the top-level of all the backend's *local* memory.
> Or skip for this specific variant context type independent
> MemoryContextCreate and init this common part itself? - (I vote for
No, certainly not. Just pass a NULL for parent if you don't want to
connect it up to the local context tree.
> Plan you some changes in SPI? I have new code for SPI save plan
> (per-context and via query cache).
I have been wondering about that. I don't like SPI saving plans in
TopMemoryContext because I don't think it knows how to get rid of them;
a plan saved there is effectively a permanent memory leak. Not sure
what to do about it though.
> And last question, is current mcxt.c API final? I want port my query cache
> to compatible with current interface.
I think it is done, though I reserve the right to change it if I find out
something needs to be done differently ;-). But what I am expecting to
do next is just modify the planner and executor to make better use of
the facilities that are there now. I won't need to change mcxt.c any
more unless I find it's too hard to use or doesn't do quite the right
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Adam Walczykiewicz||Date: 2000-06-29 07:37:20|
|Subject: SPI - documentation|
|Previous:||From: Bruce Momjian||Date: 2000-06-29 01:19:04|
|Subject: Re: LC_MESSAGES and BSD/OS|