Re: profiling connection overhead - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: profiling connection overhead
Date
Msg-id 201011300335.oAU3Zqd24335@momjian.us
Whole thread Raw
In response to Re: profiling connection overhead  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark wrote:
> On Mon, Nov 29, 2010 at 12:33 AM, Tom Lane <tgl@sss.pgh.pa.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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


pgsql-hackers by date:

Previous
From: Itagaki Takahiro
Date:
Subject: Re: pg_execute_from_file review
Next
From: Andrew Dunstan
Date:
Subject: Re: DELETE with LIMIT (or my first hack)