Manfred Koizar <[EMAIL PROTECTED]> 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...
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
