On Mon, Nov 29, 2010 at 12:33 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
