It doesn't really matter that much whether its 12, 16, 24 byte. The difference is that, given how postgres is doing it at the very least, can pass anything bigg

It doesn't really matter that much whether its 12, 16, 24 byte. The difference is that, given how postgres is doing it at the very least, can pass anything bigger than 8 byte (on 64bit arch), in general purpose registers. So function calls (which are below all operators), tuple deforming, etc, we'll instead pass those types around by reference. That always will infer another pointer indirection, and in many cases means we'll have to copy more because the datum is now dependent on the underlying tuple it has been extracted from. Whether it matters - it's hard to say so in a general manner. I'd try to avoid using a pass-by-reference type for the columns I'm aggregating billions of rows of, when reasonably possible. I'd not go to huge lengths to do so. Tuple deforming performance doesn't change much if it's a fixed width pass by reference type, rather than a variable width one.