On 2018-10-16 16:36:12 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > Attached is a patch that shrinks fmgr_builtins by 25%. That seems > > worthwhile, it's pretty frequently accessed, making it more dense is > > helpful. Unless somebody protests soon, I'm going to apply that... > > Hah. I'm pretty sure that struct *was* set up with an eye to padding ... > on 32-bit machines.
Possible, the new layout should work just as well there, luckily. > This does make it shorter on 64-bit, but also > makes the size not a power of 2, which might add a few cycles to > array indexing calculations. Might be worth checking whether that's > going to be an issue anywhere. I can't imagine that that outweight the cost of additional cache misses on any platform where performance matters. On x86 I assume indexing into an array with 24byte stride, will normally be just two leas (lea eax, [eax + eax * 2]; lea eax, [ebx + eax * 8]; where eax initially is the index, and ebx the array base). Indexing also plays less of a role than in the past, because previously we did a binary search, but now we normally look up the index via fmgr_builtin_oid_index. > What's the point of the extra const decoration on funcName? ISTM > the whole struct should be const, or not. The whole array is const. There's cases where that allows the compiler more freedom - but I guess it's really a bit redundant here. Greetings, Andres Freund
