Re: profiling connection overhead

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: profiling connection overhead
Дата
Msg-id 27759.1290990781@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: profiling connection overhead  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: profiling connection overhead  (Greg Stark <gsstark@mit.edu>)
Re: profiling connection overhead  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
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.

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.
        regards, tom lane


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.