Re: [HACKERS] Postgres Speed or lack thereof

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane)
Cc: jwieck(at)debis(dot)com, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Postgres Speed or lack thereof
Date: 1999-01-30 06:06:12
Message-ID: 199901300606.BAA08116@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-01-30 06:10:28 Re: [HACKERS] READ COMMITTED isolevel is implemented ...
Previous Message Bruce Momjian 1999-01-30 05:22:35 Re: [HACKERS] new heap manager mmalloc