On Tue, Mar 27, 2018 at 10:14 AM, Teodor Sigaev <teo...@sigaev.ru> wrote: >> b) I don't like an idea to limiting usage of that field if we can do not >> that. Future usage could use it, for example, for different compression >> technics or something else.Or even removing t_tid from inner tuples to save >> 2 bytes in IndexTupleData. Of > > course, I remember about aligment, but it could be subject to change too in > future.
This is contradictory. You seem to be arguing that we need to preserve on-disk compatibility for an optimization that throws out on-disk compatibility. Saving a single byte per internal IndexTuple is not worth it. We could actually save 2 bytes in *all* nbtree pages, by halving the size of ItemId for nbtree -- we don't need lp_len, which is redundant, and we could reclaim one of the status bits too, to get back a full 16 bits. Also, we could use suffix truncation to save at least one byte in almost all cases, even with the thinnest possible single-integer-attribute IndexTuples. What you describe just isn't going to happen. -- Peter Geoghegan