Bruce Momjian wrote:
>
> Jan Wieck wrote:
> > > I don't think enough people use pg_upgrade to make it a reason to keep
> > > an extra four bytes of tuple overhead. I realize 8-byte aligned systems
> > > don't benefit, but most of our platforms are 4-byte aligned. I don't
> > > consider redundency a valid reason either. We just don't have many
> > > table corruption complaints, and the odds that having an extra 4 bytes
> > > is going to make detection or correction better is unlikely.
> >
> > The non-overwriting storage management (which is one reason why whe need
> > all these header fields) causes over 30 bytes of row overhead anyway. I
> > am with Tom here, 4 bytes per row isn't worth making the tuple header
> > variable length size.
>
> Woh, I didn't see anything about making the header variable size. The
> issue was that on 8-byte machines, structure alignment will not allow
> any savings. However, on 4-byte machines, it will be a savings of ~11%
> in the tuple header.
You're right. Dunno where I got that idea from.
Looking at the patch I find it quite confusing using Xmin as Xmax,
sometimes. If we use 3 physical variables for 5 virtual ones in that
way, I would rather use generic names.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #