From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] new heap manager mmalloc |
Date: | 1999-07-07 01:25:12 |
Message-ID: | 199907070125.VAA29013@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I have added this to the TODO list:
* improve dynamic memory allocation by introducing tuple-context memory
allocation
* add pooled memory allocation where allocations are freed only as a
group
> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Actually, our problem is not malloc itself. Most Unix OS's have pretty
> > good malloc's, tuned to their OS. The problem is the number of times we
> > call it.
>
> Well, some malloc libs are noticeably better than others, but as long
> as the operating assumption is that any allocated block can be freed
> independently of any other one, it's hard to do a *lot* better than
> a standard malloc library. You have to keep track of each allocated
> chunk and each free area, individually, to meet malloc/free's API.
>
> What we need to do is exploit the notion of pooled allocation
> (contexts), wherein the memory management apparatus doesn't keep track
> of each allocation individually, but just takes it from a pool of space
> that will all be freed at the same time. End of statement, end of
> transaction, etc, are good pool lifetimes for Postgres.
>
> We currently have the worst of both worlds: we pay malloc's overhead,
> and we have a *separate* bookkeeping layer on top of malloc that links
> allocated blocks together to allow everything to be freed at end-of-
> context. We should be able to do this more cheaply than malloc, not
> more expensively.
>
> BTW, I already did something similar in the frontend libpq, and it
> was a considerable win for reading large SELECT results.
>
> regards, tom lane
>
--
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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-07-07 01:25:48 | Re: [HACKERS] Postgres Speed or lack thereof |
Previous Message | Bruce Momjian | 1999-07-07 00:52:23 | Re: [HACKERS] Another speedup idea (two, even) |