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.
> > The author addressed the slowness complaint and seemed to refute the
> > idea it would be slower.
>
> Do we have any hard numbers on that? Is it just access to the header
> fields, or do we loose the offset cacheability of all fixed size fields
> at the beginning of a row? In the latter case count me into the
> slowness-believer camp.
No other slowdown except access to the tuple header requires a little
more smarts. As the author mentions, the increased number of tuples per
page more than offset that. In fact, the patch is fairly small, so you
can review it yourself:
http://candle.pha.pa.us/cgi-bin/pgpatches
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
