Re: profiling connection overhead - Mailing list pgsql-hackers

From Tom Lane
Subject Re: profiling connection overhead
Date
Msg-id 27759.1290990781@sss.pgh.pa.us
Whole thread Raw
In response to Re: profiling connection overhead  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: profiling connection overhead
Re: profiling connection overhead
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.