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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers