Re: Misc. consequences of backend memory management changes - Mailing list pgsql-hackers

From Karel Zak
Subject Re: Misc. consequences of backend memory management changes
Date
Msg-id Pine.LNX.3.96.1000628192928.17152E-100000@ara.zf.jcu.cz
Whole thread Raw
In response to Misc. consequences of backend memory management changes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Misc. consequences of backend memory management changes
Re: Misc. consequences of backend memory management changes
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Big 7.1 open items
Next
From: Peter Eisentraut
Date:
Subject: Re: Big 7.1 open items