From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Sean Chittenden <sean(at)chittenden(dot)org>, "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Sort memory not being released |
Date: | 2003-06-17 15:38:51 |
Message-ID: | 13121.1055864331@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> On Tue, Jun 17, 2003 at 10:45:39AM -0400, Tom Lane wrote:
>> But essentially all our allocation traffic goes through palloc, which
>> bunches small allocations together. In typical scenarios malloc will
>> only see requests of 8K or more, so we should be in good shape on this
>> front.
> Ah, bad news. The threshold appears to be closer to 64-128KB, so for small
> allocations normal brk() calls will be made until the third or fourth
> expansion.
That's probably good, actually. I'd imagine that mmap'ing for every 8K
would be a bad idea ... until a context gets up to a few hundred K you
shouldn't get too worried about whether you can eventually give it back
to the OS.
> Obviously memory fragmentation is
> your enemy here.
True. I think the memory-context structure helps on that, but it cannot
solve it completely. (AFAIK, no one has yet done any studies to see
what sorts of memory fragmentation issues may exist in a backend that's
been running for a long while. It'd be an interesting little project
if anyone wants to take it up.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruno Wolff III | 2003-06-17 15:39:40 | Re: adddepend and partial indexes |
Previous Message | SZUCS Gábor | 2003-06-17 15:32:58 | Re: adddepend and partial indexes |