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 199901300606.BAA08116@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] Postgres Speed or lack thereof  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Postgres Speed or lack thereof  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
> 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,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Visionary
Next
From: Michael Robinson
Date:
Subject: Re: Visionary