Heikki Linnakangas <heikki@enterprisedb.com> writes:
> Saving 4 bytes per tuple with the phantom cid is nice, but saving 8
> bytes (assuming we get rid of xvac in the future, or overlay it with
> xmin for example) is even better.
xvac is not going away, so that argument is unconvincing, and I don't
believe you can avoid blowing out local memory if you have to remember
each tuple's cmin/cmax separately. (Notice that Manfred gave up on his
patch for lack of a spill-to-disk mechanism.)
I'm also concerned about loss of debug traceability if these fields
disappear entirely from disk --- it's been handy more than once to be
able to tell where in a complex transaction something happened.
Lastly, at least on machines with 8-byte MAXALIGN, removing four more
bytes from heap headers would save nothing. So I'm not excited about
going through enormous pushups to get rid of both fields, when a far
simpler and better-performing mechanism suffices to remove one.
regards, tom lane