On Thu, 19 May 2022 at 11:20, Tom Lane <t...@sss.pgh.pa.us> wrote: > The thing that makes this a bit more difficult than it might be is > the special cases we have for known-aligned and so on targets, which > are particularly critical for palloc0 and makeNode etc. So there's > more than one case to look into. But I'd argue that those special > cases are actually what we want to worry about the most: zeroing > relatively small, known-aligned node structs is THE use case.
I think the makeNode() trickery would be harder to get rid of, or for that matter, anything where the size/alignment is unknown at compile time. I think the more interesting ones that we might be able to get rid of are the ones where the alignment and size *are* known at compile time. Also probably anything that passes a compile-time const that's not 0 will fallback on memset anyway, so might as well be removed to tidy things up. It just all seems a bit untidy when you look at functions like ExecStoreAllNullTuple() which use a mix of memset and MemSet without any apparent explanation of why. That particular one is likely that way due to the first size guaranteed to be multiples of sizeof(Datum) and the latter not. Naturally, we'd need to run enough benchmarks to prove to ourselves that we're not causing any slowdowns. The intention of memset.c was to try to put something out there that people could test so we could get an idea if there are any machines/compilers that we might need to be concerned about. David