Re: [HACKERS] Postgres Speed or lack thereof
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Postgres Speed or lack thereof |
Дата | |
Msg-id | 199901300606.BAA08116@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Postgres Speed or lack thereof (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Postgres Speed or lack thereof
|
Список | 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 по дате отправления: