"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> Heikki Linnakangas <heikki@enterprisedb.com> 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