Skip site navigation (1) Skip section navigation (2)

Re: profiling connection overhead

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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 01:28:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> BTW, this might be premature to mention pending some tests about mapping
> versus zeroing overhead, but it strikes me that there's more than one
> way to skin a cat.  I still think the idea of statically allocated space
> sucks.  But what if we rearranged things so that palloc0 doesn't consist
> of palloc-then-memset, but rather push the zeroing responsibility down
> into the allocator?  In particular, I'm imagining that palloc0 with a
> sufficiently large space request --- more than a couple pages --- could
> somehow arrange to get space that's guaranteed zero already.  And if the
> request isn't large, zeroing it isn't where our problem is anyhow.

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

Yes, I was going to suggest trying calloc(), either because we can get
already-zeroed sbrk() memory, or because libc uses assembly language for
zeroing memory, as some good libc's do.  I know most kernels also use
assembly for zeroing memory.

> Another question that would be worth asking here is whether the
> hand-baked MemSet macro still outruns memset on modern architectures.
> I think it's been quite a few years since that was last tested.

Yes, MemSet was found to be faster than calling a C function, but new
testing is certainly warranted.

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + It's impossible for everything to be true. +

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2010-11-30 01:34:06
Subject: Re: profiling connection overhead
Previous:From: Bruce MomjianDate: 2010-11-30 01:13:26
Subject: Re: profiling connection overhead

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group