Re: [HACKERS] Postgres Speed or lack thereof
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Postgres Speed or lack thereof |
Дата | |
Msg-id | 199903151443.JAA12545@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Postgres Speed or lack thereof (Bruce Momjian <maillist@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 (jwieck@debis.com (Jan Wieck)) |
Список | 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 по дате отправления: