Re: Tuple alignment

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Heikki Linnakangas <heikki(at)enterprisedb(dot)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