I wrote: > On a micro level, this makes sizeof(IndexTupleData) be not maxaligned, > which is likely to cause problems on alignment-picky hardware, or else > result in space wastage if we were careful to MAXALIGN() everywhere. > (Which we should have been, but I don't care to bet on it.) A lot of > people would be sad if their indexes got noticeably bigger when they > weren't getting anything out of that.
After thinking about that a bit more, there might be a way out that both avoids bloating index tuples that don't need it, and avoids the compatibility problem. How about defining that if the INDEX_SIZE_MASK bits aren't zero, they are the tuple size as now; but if they are zero, then the size appears in a separate uint16 field following the existing IndexTupleData fields. We could perhaps also rethink how the nulls bitmap storage works in this "v2" index tuple header layout? In any case, I'd expect to end up in a place where (on 64-bit hardware) you pay an extra MAXALIGN quantum for either an oversize tuple or a nulls bitmap, but only one quantum when you have both, and nothing above today when the tuple is not oversize. This'd complicate tuple construction and inspection a bit, but it would avoid building an enormous lot of infrastructure to deal with transitioning to a not-upward-compatible definition. regards, tom lane