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.
>
> > 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.
Here is a summary of the concepts used in the patch:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=ejf4du853mblm44f0u78f02g166r69lng7%404ax.com&rnum=28&prev=/groups%3Fq%3Dmanfred%2Bkoizar%2Bgroup:comp.databases.postgresql.*%26start%3D20%26hl%3Den%26lr%3D%26ie%3DUTF-8%26scoring%3Dd%26selm%3Dejf4du853mblm44f0u78f02g166r69lng7%25404ax.com%26rnum%3D28
--
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
