Re: profiling connection overhead

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: profiling connection overhead
Дата
Msg-id AANLkTi=G8yC+JarrLT7y3NBF2DcKGm9FbAXW8rQjABMZ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: profiling connection overhead  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: profiling connection overhead  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: profiling connection overhead  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
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?


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

I know glibc has some sexy memset macros for cases where the size is a
constant. I'm not sure there's been much of an advance in the general
case though. This would tend to imply we should consider going the
other direction of having the caller of palloc0 do the zeroing
instead. Or making palloc0 a macro which expands to include calling
memset with the parameter inlined.


--
greg


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Report: Linux huge pages with Postgres
Следующее
От: Tom Lane
Дата:
Сообщение: Re: profiling connection overhead