Re: [HACKERS] Postgres Speed or lack thereof

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: maillist(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian)
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, jwieck(at)debis(dot)com, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Postgres Speed or lack thereof
Date: 1999-03-15 14:43:46
Message-ID: 199903151443.JAA12545@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(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
>
>

--
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-03-15 14:44:40 Re: [HACKERS] Patch (was: tough locale bug)
Previous Message Bruce Momjian 1999-03-15 14:37:47 Re: [HACKERS] Another speedup idea (two, even)