From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Subject: | Re: profiling connection overhead |
Date: | 2010-11-30 03:35:52 |
Message-ID: | 201011300335.oAU3Zqd24335@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark wrote:
> On Mon, Nov 29, 2010 at 12:33 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > The most portable way to do that would be to use calloc insted of malloc,
> > and hope that libc is smart enough to provide freshly-mapped space.
> > It would be good to look and see whether glibc actually does so,
> > of course. ?If not we might end up having to mess with sbrk for
> > ourselves, and I'm not sure how pleasantly that interacts with malloc.
>
> It's *supposed* to interact fine. The only thing I wonder is that I
> think malloc intentionally uses mmap for larger allocations but I'm
> not clear what the advantages are. Is it because it's a cheaper way to
> get zeroed bytes? Or just so that free has a hope of returning the
> allocations to the OS?
Using mmap() so you can return large allocations to the OS is a neat
trick, certainly. I am not sure who implements that.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2010-11-30 04:25:17 | Re: DELETE with LIMIT (or my first hack) |
Previous Message | Itagaki Takahiro | 2010-11-30 03:25:07 | Re: pg_execute_from_file review |