Re: Per tuple overhead, cmin, cmax

Manfred Koizar <mkoi-pg@aon.at> writes:
> Let me throw in one of my infamous wild ideas in an attempt to rescue
> my proposal:  We have 4 32-bit-numbers: xmin, cmin, xmax, and cmax.
> The only case, where we need cmin *and* cmax, is, when xmin == xmax.
> So if we find a single bit to flag this case, we only need 3
> 32-bit-numbers to store this information on disk.

Hmm ... that might work.  Actually, we are trying to stuff *five*
numbers into these fields: xmin, xmax, cmin, cmax, and a VACUUM FULL
transaction id (let's call it xvac just to have a name).  The code
currently assumes that cmin is not interesting simultaneously with xvac.
I think it might be true that cmax is not interesting simultaneously
with xvac either, in which case this could be made to work.  (Vadim,
your thoughts?)

> To keep the code readable we probably would need some accessor
> functions or macros to access these fields.

Amen.  But that would be cleaner than now, at least for VACUUM;
it's just using cmin where it means xvac.

> Is saving 4 bytes per tuple a "darn good reason"?  Is a change
> acceptable for 7.3?  Do you think it's worth the effort?

I'm on the fence about it.  My thoughts are probably colored by the
fact that I prefer platforms that have MAXALIGN=8, so half the time
(including all null-free rows) there'd be no savings at all.  Now if
we could get rid of 8 bytes in the header, I'd get excited ;-)

Any other opinions out there?
        regards, tom lane

PS: I did like your point about BITMAPLEN; I think that might be
a free savings.  I was waiting for you to bring it up on hackers
before commenting though...