Re: [HACKERS] Postgres Speed or lack thereof - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] Postgres Speed or lack thereof
Date
Msg-id 199903151443.JAA12545@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] Postgres Speed or lack thereof  (Bruce Momjian <maillist@candle.pha.pa.us>)
Responses Re: [HACKERS] Postgres Speed or lack thereof
Re: [HACKERS] Postgres Speed or lack thereof
List pgsql-hackers
Can someone remind me where we left this memory context stuff?



> > I've noticed that everyone else contributing to this thread has been
> > thinking in terms of inventing multiple allocation functions with
> > different names, ie a routine might have to call "palloc" or
> > "fast_palloc" or "tmp_palloc" or whatever depending on what behavior it
> > wants.  I really think we are better off to stick to the structure that
> > we already have (cf. include/nodes/memnodes.h and include/utils/mcxt.h),
> > in which there's one set of interface routines that take a "context"
> > parameter, and the context determines the semantics of allocation.
> > (The interface routines probably ought to be macros, not out-of-line
> > code, but that's a minor optimization.)  This will make it easier to
> > handle cases where one routine has to tell another one how to allocate
> > its result space: you pass a MemoryContext parameter.
> 
> I agree, inline is good.  I can imagine something like makeNode is going
> to be tough.
> 
> I am going to give the parser as an example.  It palloc's all sorts of
> things for rangetables, strings, structures, lists, but eventually just
> exports a huge Query structure.
> 
> If we could somehow just grab copy Query structure and free all the
> other parser palloc allocations, that would be great.
> 
> Same thing with the optimizer.  It makes all sorts of lists, but
> eventuall just exports Plan's.  All the other stuff can be pfree'ed.
> 
> It is almost as though we could copy the Query structure to another
> memory context, and just fee all palloc'ed memory.
> 
> What we could try is to keep the various memory contexts like cache
> context unchanged, but allow pallocs in the standard memory context to
> be allocated from a pool and free'ed automatically.  Our standard memory
> context is overused and doesn't need the pfree overhead.  We could make
> palloc a macro that tested for the current context, and did standard
> pallocs from a free memory pool.
> 
> -- 
>   Bruce Momjian                        |  http://www.op.net/~candle
>   maillist@candle.pha.pa.us            |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
> 
> 


--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Patch (was: tough locale bug)
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] char(n) default '' crashes server