Re: profiling connection overhead

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. +

In response to

Browse pgsql-hackers by date

  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