"Tom Lane" <[EMAIL PROTECTED]> writes: > Heikki Linnakangas <[EMAIL PROTECTED]> writes: >> Why do we require that t_hoff is MAXALIGNed? ISTM that if the first >> field in a tuple doesn't require alignment, it could be stored >> immediately after the null bitmap, without padding. > > Then the intra-tuple alignment would be unpredictable.
At first I thought that was a killer problem too. But on further thought I could only think of one thing that actually depends on consistent intra-tuple alignment: the cache offset in the tupledesc used by heaptuple.c. It's probably too gross to consider but in fact we could work around this problem. At the limit we could keep 8 cache offsets for the 8 possible alignments of t_hoff. But I think we could be cleverer. If we kept track of the "normal" offset for the maxaligned t_hoff then any field would only ever be up to 7 bytes offset from that. As you meet fields with larger and larger alignment eventually fields would be back to their normal alignment if you mean a maxaligned field. So the "correct" place to find any field is cached normal alignment - (t_hoff aligned to largest alignment seen on earlier fields - t_hoff) This depends on an assumption which is true in C but perhaps not for Postgres datatypes: sizeof(datatype) is an integral multiple of alignof(datatype) for all data types. I'm not sure it's worth bothering with this given that the space savings possible is bounded to a fixed alignment per tuple. For tuples with 8 fields or under there's usually going to be no savings at all. I just thought I would get this down and in the mail archives before I forget it. > The OID trick doesn't work very well either. expn "OID trick"? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
